From jbloom@arrl.org Fri Nov 01 11:40:08 1996 
Received: from mgate.arrl.org (root@mgate.arrl.org [205.217.201.2]) by tapr.org 
(8.7.5/8.7.3/1.9) with SMTP id LAA28714 for <hfsig@tapr.org>; Fri, 1 Nov 1996 
11:40:05 -0600 (CST) 
Received: from smtp_gw by mgate.arrl.org with smtp 
(Smail3.1.29.1 #9) id mOvJNZc-O000f5hC; Fri, 1 Nov 96 12:40 EST 
Message-Id: <mOvJNZc-000f5hC@mgate.arrl.org> 
Priority: urgent 
Date: Fri, 1 Nov 1996 12:38:00 -0500 
From: "Bloom, Jon, KE3Z" <jbloom@arrl.org> 
Subject: FW: Wavecom W41PC DSP data decoder card 
To: "'hfsig@tapr.org'" <hfsig@tapr.org> 
X-Mailer: Worldtalk (NetConnex V4.00a) /MIME 


This bounced around the HQ email system until it landed in my inbox. 
Might be of interest to some on this group, I thought. 


-- Jon, KE3Z 


Date: 31 Oct 96 10:02:26 EST 

From: Joerg Klingenfuss <101550.514@CompuServe. COM> 

To: BlindCopyReceiver: ;@compuserve.com 

Subject: Wavecom W41PC DSP data decoder card 

Message-ID: <961031150226_101550.514_ THK54-1@CompuServe. COM> 


Dear friends 


we would like to draw your attention to the brandnew Wavecom W41PC DSP 
data 

analyzer and decoder card for Windows 95 PC systems. This professional 
equipment 

is now available and it is really the ultimate decoder. We will start 
distribution in early December and our "waiting list" is now open. For a 
detailed description and some sample colour screenshots please refer to 
http: //ourworld.compuserve.com/homepages/Klingenfuss/ . A free colour 
brochure 

will be available soon. Thank you for your interest, and best wishes for 
the 

main listening season! 


73 es best DX, Joerg Klingenfuss 


Klingenfuss Radio Monitoring 

Hagenloher Str. 14 

D-72070 Tuebingen 

Germany 

Phone ++49 7071 62830 

Fax ++49 7071 600849 

E-Mail 101550.514@compuserve.com 

WWW-Site http://ourworld.compuserve.com/homepages/Klingenfuss/ 


From forrerj@peak.org Sun Nov 03 21:05:09 1996 

Received: from PEAK.ORG (root@PEAK.ORG [198.68.22.17]) by tapr.org 
(8.7.5/8.7.3/1.9) with SMTP id VAAQ8201 for <HFSIG@TAPR.ORG>; Sun, 3 Nov 1996 
21:05:07 -0600 (CST) 

Received: from p01.tO.monrotel.com (p02.tO.monrotel.com [198.68.25.35]) by 
PEAK.ORG (8.6.13/8.6.7) with SMTP id TAA17295 for <HFSIG@TAPR.ORG>; Sun, 3 Nov 
1996 19:05:10 -0800 

Message-Id: <199611040305.TAA17295@PEAK.ORG> 

X-Sender: forrerj@peak.org 

X-Mailer: Windows Eudora Version 1.4.4 

Mime-Version: 1.0 

Content-Type: text/plain; charset="us-ascii" 

Date: Sun, 03 Nov 1996 19:06:41 -0800 

To: HFSIG@tapr.org 

From: forrerj@peak.org (Johan Forrer) 

Subject: DSP/Modem article 


Hi, 


Thought I would mention a recent article in Circuit Cellar INK 
(November 1996) that may be of interest. 


Page 20; "Real-Time DSP Modems with a PC and Sound Card". 


Covers some experimental work on a V.22 modem that can run ona 
486 class PC with a sound card. Source code in C and assembly 
are included. Interesting article if you have not yet been 
introduced to modem theory and techniques. 


Page 14; "Bulding a High-Performance DSP System" 


Covers the architecture for the EZ-Kit. Quite informative if 
you have not used the latest ADSP-21xx family chips. Actually 
the chip has a neat DMA channel that is worth something but 
not given much attention in the article. 


--Johan 


From jsanfor@exis.net Mon Nov 04 05:42:06 1996 

Received: from marlin.exis.net (root@marlin.exis.net [205.252.72.102]) by tapr.org 
(8.7.5/8.7.3/1.9) with ESMTP id FAA01720 for <hfsig@tapr.org>; Mon, 4 Nov 1996 
05:42:05 -0600 (CST) 

Received: from PENTIUM (ppp-2-58.exis.net [205.252.76.58]) by marlin.exis.net 
(8.7.6/8.7.3) with SMTP id GAA24342 for <hfsig@tapr.org>; Mon, 4 Nov 1996 06:42:02 
-0500 

Message-ID: <327DD68B.36D6@exis.net> 

Date: Mon, 04 Nov 1996 06:42:03 -0500 

From: Jim Sanford <jsanfor@exis.net> 

Reply-To: wb4gcs@amsat.org 

Organization: WB4GCS 

X-Mailer: Mozilla 3.0 (Win16; U) 

MIME-Version: 1.0 

To: hfsig@tapr.org 


Subject: Re: [HFSIG:1687] DSP/Modem article 
References: <199611040305.TAA17295@PEAK.ORG> 
Content-Type: text/plain; charset=us-ascii 
Content-Transfer-Encoding: 7bit 


Johan Forrer wrote: 
Hi, 


Thought I would mention a recent article in Circuit Cellar INK 
(November 1996) that may be of interest. 


Page 20; "Real-Time DSP Modems with a PC and Sound Card". 


Covers some experimental work on a V.22 modem that can run ona 
486 class PC with a sound card. Source code in C and assembly 
are included. Interesting article if you have not yet been 
introduced to modem theory and techniques. 


Page 14; "Bulding a High-Performance DSP System" 


Covers the architecture for the EZ-Kit. Quite informative if 
you have not used the latest ADSP-21xx family chips. Actually 
the chip has a neat DMA channel that is worth something but 
not given much attention in the article. 


VV VV VV VV VV VV VV VV VV VV 


> --Johan 

Johan: 

Not familiar with this magazine . .. where do I get one? Is 
"Circuit Cellar" the name of the mag???? 


Thanks, Jim 
wb4gcs@amsat.org 


From rlanier@su102s.ess.harris.com Mon Nov 04 07:42:42 1996 
Received: from ess.harris.com (sul5a.ess.harris.com [130.41.1.251]) by tapr.org 
(8.7.5/8.7.3/1.9) with SMTP id HAAQ5109 for <hfsig@tapr.org>; Mon, 4 Nov 1996 
07:42:41 -0600 (CST) 
Received: from su102s.ess.harris.com by ess.harris.com (5.x/SMI-SVR4) 
id AAQ3487; Mon, 4 Nov 1996 08:42:38 -0500 
Received: from Sopchoppy.GASD102designcenter by sul102s.ess.harris.com (4.1/ 
SMI-4.1) 
id AA15904; Mon, 4 Nov 96 08:42:35 EST 
Received: by Sopchoppy.GASD102designcenter (SMI-8.6/SMI-SVR4) 
id IAA17814; Mon, 4 Nov 1996 08:42:32 -0500 
Date: Mon, 4 Nov 1996 08:42:32 -0500 
From: rlanier@su102s.ess.harris.com (Tony Lanier) 
Message-Id: <199611041342.IAA17814@Sopchoppy .GASD102designcenter> 
To: hfsig@tapr.org 
Subject: Re: [HFSIG:1688] Re: DSP/Modem article 
X-Sun-Charset: US-ASCII 


> From hfsig@tapr.org Mon Nov 4 08:00:28 1996 


VV VVV VV VV VV VV VV VV VV VV VV VV VV VV VV VV VV VV WV 


Date: Mon, 4 Nov 1996 05:42:30 -0600 (CST) 

Originator: hfsig@tapr.org 

From: Jim Sanford <jsanfor@exis.net> 

To: hfsig@tapr.org 

Subject: [HFSIG:1688] Re: DSP/Modem article 

X-Listprocessor-Version: 6.0 -- ListProcessor by Anastasios Kotsikonas 
X-Comment: Tucson Amateur Packet Radio HF Special Interest Group 
Content-Transfer-Encoding: 7bit 

Mime-Version: 1.0 


Johan Forrer wrote: 
Hi, 


Thought I would mention a recent article in Circuit Cellar INK 
(November 1996) that may be of interest. 


Page 20; "Real-Time DSP Modems with a PC and Sound Card". 


Covers some experimental work on a V.22 modem that can run ona 
486 class PC with a sound card. Source code in C and assembly 
are included. Interesting article if you have not yet been 
introduced to modem theory and techniques. 


Page 14; "Bulding a High-Performance DSP System" 


Covers the architecture for the EZ-Kit. Quite informative if 
you have not used the latest ADSP-21xx family chips. Actually 
the chip has a neat DMA channel that is worth something but 
not given much attention in the article. 


VVVV VV VV VV VV VV VV VV VM 


> --Johan 

Johan: 

Not familiar with this magazine . .. where do I get one? Is 
"Circuit Cellar" the name of the mag???? 


Thanks, Jim 
wb4gcs@amsat.org 


What issue is it in? 


Tony, KE4ATO 


From sailer@ife.ee.ethz.ch Mon Nov 04 09:39:18 1996 

Received: from ife.ee.ethz.ch (ife-ifel.ee.ethz.ch [129.132.25.65]) by tapr.org 
(8.7.5/8.7.3/1.9) with ESMTP id JAA09911 for <hfsig@tapr.org>; Mon, 4 Nov 1996 
09:39:15 -0600 (CST) 

Received: from eldrich.ee.ethz.ch (eldrich.ee.ethz.ch [129.132.25.145]) by 
ife.ee.ethz.ch (8.8.2/8.8.2) with SMTP id QAA27156 for <hfsig@tapr.org>; Mon, 4 
Nov 1996 16:38:44 +0100 (MET) 

Sender: sailer@ife.ee.ethz.ch 

Message-ID: <327E0E03.2783@ife.ee.ethz.ch> 

Date: Mon, 04 Nov 1996 16:38:43 +0100 


From: Thomas Sailer <sailer@ife.ee.ethz.ch> 
Organization: IfE 

X-Mailer: Mozilla 3.0 (X11; I; SunOS 5.5 sun4m) 
MIME-Version: 1.0 

To: hfsig@tapr.org 

Subject: Re: DSP/Modem article 

References: <199611040305.TAA17295@PEAK.ORG> 
Content-Type: text/plain; charset=us-ascii 
Content-Transfer-Encoding: 7bit 


While we're at implementing modems using general purpose 
PC's and soundcards, some remarks from my side: 


Linux 2.1.7, which was released half week ago, now 

contains my packet radio drivers for general purpose 

sound cards. It works with Soundblaster and WindowsSoundSystem 
compatible soundcards. The drivers can do either 1200 baud AFSK 
or 9600 baud G3RUH compatible FSK. Since this is Linux, 

it comes with sources :-). It should be reasonnably easy 

to add FEC for those who want :-) 

The driver offers a network driver interface and can thus be 
easily used with kernel AX.25, in theory at least. Unfortunately, 
kernel AX.25 does not compile in 2.1.7 because of changes 

in the user access primitives in the kernel. The drivers may 
however be used by user mode ax25 stacks such as WAMPES, which 
can now directly access kernel AX.25 stacks. 


But to slow down your enthusiasm, here are the top 8 reasons 
why a general purpose Soundcard and a PC is _NOT_ a good 
signal processing platform: 


1. Bad analog section of many soundcards. Frequency response 
and/or noise leaves much to be desired. 


2. Low resolution or sampling rates are still common. SBPro 
can't do 16bits! WSS cards are somehow better... 


3. A garden variety of "almost compatible" soundcards makes 
life hard. Even Creative's Cards aren't fully backwards 
compatible 


4. Full duplex cards are still the exception. Creative's 

idea of "full duplex" operation is to stick in two soundcards. 

This results in ADC and DAC sampling frequencies not being exactly 
the same which may cause further difficulties depending on the 
application (consider an effect processor. You just cannot output 
the data sampled by one soundcard on the other soundcard, you would 
have to do complicated sample rate conversions) 


5. You cannot usually use the OS driver for the soundcard. 
Using it would result in switching times from transmission 
to reception and vice versa to be in the seconds range, 
which is unacceptable for example for packet radio. 


Having to drive the cards yourself exposes you to all the 
braindamage of current soundcard architectures 


6. It is very nontrivial to attach a time tag to each sample, 
i.e. to know or specify exactly when a sample should be output. 
This is needed for protocols with a rigid timing scheme, such as 
4Am,PactTor. This makes them virtually useless for many HF 
protocols. 


7. There is not one common sampling frequency every soundcard 
can produce, i.e. every brand of soundcard seems to have 
a distinct set of sampling frequencies available. 


8. Point 7 would not be too bad if one could find out the 
actual sampling frequency used. However the actual baud rate 
and the rate the soundcard reports to use may differ in 

the percent region! This does not matter very much for 
audio, but this is bad news for example for PSK. 


IMHO it boils down to: 

- current soundcards have a braindamaged interface on the 
digital side 

- the designers of the analog circuitry seem to be completely 
unaware of digital signal processing. 

Of course there are exceptions to this rule. WSS soundcards 

seem to be better because the CODEC chip comes from one 

of two companies (Analog Devices or Crystal Semiconductors) that 

know this field very well. 


Tom 
hb9jnx/ae4wa 


From forrerj@peak.org Mon Nov 04 11:54:54 1996 

Received: from PEAK.ORG (root@PEAK.ORG [198.68.22.17]) by tapr.org 
(8.7.5/8.7.3/1.9) with SMTP id LAA16752 for <hfsig@tapr.org>; Mon, 4 Nov 1996 
11:54:53 -0600 (CST) 

Received: from p05.tO.monrotel.com (p07.tO.monrotel.com [198.68.25.40]) by 
PEAK.ORG (8.6.13/8.6.7) with SMTP id JAAQ1919 for <hfsig@tapr.org>; Mon, 4 Nov 
1996 09:55:02 -0800 

Message-Id: <199611041755.JAAQ1919@PEAK.ORG> 

X-Sender: forrerj@peak.org 

X-Mailer: Windows Eudora Version 1.4.4 

Mime-Version: 1.0 

Content-Type: text/plain; charset="us-ascii" 

Date: Mon, 04 Nov 1996 09:56:38 -0800 

To: hfsig@tapr.org 

From: forrerj@peak.org (Johan Forrer) 

Subject: Re: [HFSIG:1687] DSP/Modem article 


>Hi, 
> 
>Thought I would mention a recent article in Circuit Cellar INK 


>(November 1996) that may be of interest. 


PAVAYAVAVALAVAVATATAVATATAS 


Issue #76 
http: //www.circellar.com/ 


I have been an avid reader of this very down-to-earth journal 
and have gained a lot from it. 


--Johan 


From mcdermot@rdxsunhost.aud.alcatel.com Wed Nov 06 14:58:24 1996 
Received: from aud.alcatel.com (rockdal.aud.alcatel.com [128.251.30.1]) by 
tapr.org (8.7.5/8.7.3/1.9) with SMTP id OAA24005 for <hfsig@tapr.org>; Wed, 6 Nov 
1996 14:58:23 -0600 (CST) 
Received: from rdxsunhost.aud.alcatel.com.Aud.Alcatel.COM by aud.alcatel.com (4.1/ 
SMI-4.1) 
id AA09700; Wed, 6 Nov 96 14:58:22 CST 
Received: from eagle.aud.alcatel.com by rdxsunhost.aud.alcatel.com.Aud.Alcatel.COM 
(4.1/SMI-4.1) 
id AA16517; Wed, 6 Nov 96 14:58:21 CST 
Received: by eagle.aud.alcatel.com (4.1/SMI-4.1) 
id AAQ3299; Wed, 6 Nov 96 14:58:20 CST 
Date: Wed, 6 Nov 96 14:58:20 CST 
From: mcdermot@rdxsunhost.aud.alcatel.com (Tom Mcdermott) 
Message-Id: <9611062058.AA03299@eagle.aud.alcatel.com> 
To: hfsig@tapr.org 
Subject: PSAM (IEEE Comm, Nov '96) 


An interesting article in the latest (Nov 96?) issue 
of IEEE Communications magazine on 220 Mhz mobile data services. 
It discusses multipath fading, and moving vehicles, diversity, 
etc. 


One technique discussed is PSAM - Periodic Symbol Assisted 
Modulation. The transmitter sends periodically in the frame a known 
symbol. Acutally, the periodic symbol is from a set of symbols, so 
the periodic symbols do not disturb the modulation stastics too much. 


Even with fast fading of driving a car, the multipath 
fading is strictly band-limited. Thus looking at the periodic symbol 
gives a way to estimate the channel response, and a way to update 
that estimate with time. 


There is an example of a 16-QAM constellation which is 
totally useless, but when divided by the channel estimator resolves 
into a 16-point constellation quite nicely. 


It would seem that this idea might be extended to HF, since 
the multipath on HF is also, I think strictly band limited. The 
periodic symbol allows to compensate well for amplitude variations, 


and thus may open up the possibility of the very useful QAM modulation 
on HF. 16-QAM is about 4 dB more efficient, in terms of Eb/No, than 
16-PSK, but it's tough on HF with the constantly changing amplitude. 


Anyone else seen this article and care to comment on whether it 
might be useful on HF? 


- Tom 


Tom McDermott 
mcdermot@aud.alcatel.com 


From zsolt@direct.ca Wed Nov 06 16:01:40 1996 

Received: from aphex.direct.ca (root@aphex.direct.ca [199.60.229.6]) by tapr.org 
(8.7.5/8.7.3/1.9) with ESMTP id QAA26375 for <hfsig@tapr.org>; Wed, 6 Nov 1996 
16:01:38 -0600 (CST) 

Received: from boxer.direct.ca (van-pm-0508.direct.ca [204.174.243.128]) by 
aphex.direct.ca (8.8.0/8.8.0) with SMTP id OAAQ4520; Wed, 6 Nov 1996 14:01:28 
-Q800 (PST) 

Date: Wed, 6 Nov 1996 15:04:15 -0800 (PST) 

From: George Cserenyi <zsolt@direct.ca> 

To: Tom Mcdermott <mcdermot@rdxsunhost.aud.alcatel.com> 

cc: hfsig@tapr.org 

Subject: Re: [HFSIG:1692] PSAM (IEEE Comm, Nov '96) 

In-Reply-To: <9611062058.AA03299@eagle.aud.alcatel.com> 

Message-ID: <Pine.LNX.3.91.961106144825 .15342A-100000@boxer.direct.ca> 
MIME-Version: 1.0 

Content-Type: TEXT/PLAIN; charset=US-ASCII 


On Wed, 6 Nov 1996, Tom Mcdermott wrote among other things: 


An interesting article in the latest (Nov 96?) issue 
of IEEE Communications magazine on 220 Mhz mobile data services. 
It discusses multipath fading, and moving vehicles, diversity, 
etc. 
vel 

It would seem that this idea might be extended to HF, since 
the multipath on HF is also, I think strictly band limited. The 
periodic symbol allows to compensate well for amplitude variations, 
and thus may open up the possibility of the very useful QAM modulation 
on HF. 16-QAM is about 4 dB more efficient, in terms of Eb/No, than 
16-PSK, but it's tough on HF with the constantly changing amplitude. 
eel 
Tom McDermott 
mcdermot@aud.alcatel.com 


VVVMmMmV VV VV V mV VV VV 


Haven't got the chance to read that article, but found ur thoughts 


on HF multipath interesting. 

What practical advantage do you see by using 16-QAM modulation on HF? 
What modes would it be most useful for? 

What equipment is needed for HF use? Cost? Avaibility? 

These are open questions to everyone on the list BTW. 


I for one, would like to experiment with it. 

Am long on time but short on money since retired from active work. 
Is alcatel a swiss company? 

73, George 

ve7ciz 


From alanb@polecat.sr.hp.com Wed Nov 06 19:40:44 1996 
Received: from hp.com (hp.com [15.255.152.4]) by tapr.org (8.7.5/8.7.3/1.9) with 
ESMTP id TAAQ6483 for <hfsig@tapr.org>; Wed, 6 Nov 1996 19:40:07 -Q600 (CST) 
Received: from srmail.sr.hp.com by hp.com with ESMTP 
(1.37.109.16/15.5+ECS 3.3) id AA288150802; Wed, 6 Nov 1996 17:40:03 -0800 
Received: from polecat.sr.hp.com (algae.sr.hp.com) by srmail.sr.hp.com with ESMTP 
(1.37.109.16/15.5+ECS 3.3) id AAQ52680801; Wed, 6 Nov 1996 17:40:02 -0800 
Received: by polecat.sr.hp.com 
(1.37.109.16/15.5+ECS 3.3) id AA187840801; Wed, 6 Nov 1996 17:40:01 -0800 
From: Alan Bloom <alanb@polecat.sr.hp.com> 
Message-Id: <199611070140.AA187840801@polecat.sr.hp.com> 
Subject: Amplitude calibration 
To: hfsig@tapr.org 
Date: Wed, 6 Nov 1996 17:40:00 -0800 (PST) 
X-Mailer: ELM [version 2.4 PL21] 
Mime-Version: 1.0 
Content-Type: text/plain; charset=US-ASCII 
Content-Transfer-Encoding: 7bit 


mcdermot@rdxsunhost.aud.alcatel.com (Tom Mcdermott) wrote: 


>One technique discussed is PSAM - Periodic Symbol Assisted 
>Modulation. The transmitter sends periodically in the frame a known 
>symbol. Acutally, the periodic symbol is from a set of symbols, so 
>the periodic symbols do not disturb the modulation stastics too much. 


De os The 

>periodic symbol allows to compensate well for amplitude variations, 
>and thus may open up the possibility of the very useful QAM modulation 
>on HF. 


It sounds like a very interesting idea. One variation would be the 
following: Rather than sending a periodic known symbol, scramble the 
input data with a known pseudo-random sequence. That would guarantee 
that all possible symbol states occur at approximately equal rates. 
Then you could use AGC in the receiver to compensate for fading. 


The AGC time constant would have to be long enough to integrate enough 

symbols to obtain a good average amplitude. But the time constant would 
also have to be short with respect to the fastest fade times. I suspect 
that typical values used in HF SSB receivers would be about right, since 


they have the same bandwidth ("data rate") and fading constraints. 


A similar problem exists with the periodic-symbol approach -- the known 
symbol must occur much more often than the fade time, but not so often 
that it affects throughput. 


A third variation would be to use both techniques together. Scrambling 
would allow receiver AGC to keep the input to the demodulator at the 
optimum level for best dynamic range, while the periodic known symbol 
would allow the demod to dial in a fine amplitude adjustment. 


Alan Bloom N1AL 


From chbrain@dircon.co.uk Thu Nov 07 01:02:57 1996 
Received: from felix.dircon.co.uk (felix.dircon.co.uk [193.128.224.10]) by 
tapr.org (8.7.5/8.7.3/1.9) with SMTP id BAA25017 for <hfsig@tapr.org>; Thu, 7 Nov 
1996 01:02:54 -0600 (CST) 
Received: by felix.dircon.co.uk id AAQ4051 
(5.67b/IDA-1.5 for <hfsig@tapr.org>); Thu, 7 Nov 1996 06:59:45 GMT 
Received: from gw2-115.pool.dircon.co.uk(194.112.35.115) by amnesiac via smap 
(V1.3) 
id sma004039; Thu Nov 7 06:59:20 1996 
Message-Id: <1.5.4.32.19961107065457 .0068b218@popmail.dircon.co.uk> 
X-Sender: chbrain@popmail.dircon.co.uk 
X-Mailer: Windows Eudora Light Version 1.5.4 (32) 
Mime-Version: 1.0 
Content-Type: text/plain; charset="us-ascii" 
Date: Thu, 07 Nov 1996 06:54:57 +0000 
To: hfsig@tapr.org 
From: Charles Brain <chbrain@dircon.co.uk> 
Subject: Re: [HFSIG:1692] PSAM (IEEE Comm, Nov '96) 


> One technique discussed is PSAM - Periodic Symbol Assisted 
>Modulation. The transmitter sends periodically in the frame a known 
>symbol. Acutally, the periodic symbol is from a set of symbols, so 
>the periodic symbols do not disturb the modulation stastics too much. 

> 

> 

Am I missing something here or are we talking about training sequencies, 
if so HF serial tone modems use this technique combined with 

decision directed equalisation to update their adaptive equalisers. 


Charles G4GUO 


From mcdermot@rdxsunhost.aud.alcatel.com Thu Nov 07 13:20:07 1996 
Received: from aud.alcatel.com (rockdal.aud.alcatel.com [128.251.30.1]) by 
tapr.org (8.7.5/8.7.3/1.9) with SMTP id NAA19923 for <hfsig@tapr.org>; Thu, 7 Nov 
1996 13:20:05 -0600 (CST) 
Received: from rdxsunhost.aud.alcatel.com.Aud.Alcatel.COM by aud.alcatel.com (4.1/ 
SMI-4.1) 

id AAQ2306; Thu, 7 Nov 96 13:20:03 CST 
Received: from eagle.aud.alcatel.com by rdxsunhost.aud.alcatel.com.Aud.Alcatel.COM 


(4.1/SMI-4.1) 
id AA23011; Thu, 7 Nov 96 13:20:02 CST 
Received: by eagle.aud.alcatel.com (4.1/SMI-4.1) 
id AAQ3465; Thu, 7 Nov 96 13:20:01 CST 
Date: Thu, 7 Nov 96 13:20:01 CST 
From: mcdexrmot@rdxsunhost.aud.alcatel.com (Tom Mcdermott) 
Message-Id: <9611071920.AA03465@eagle.aud.alcatel.com> 
To: hfsig@tapr.org 
Subject: Correction: PSAM (IEEE Comm, Oct '96) 


The 220 Mhz article containing (among other topics) PSAM 
(Periodic Symbol-Assisted Modulation) article was in October '96 
IEEE Communications magazine. It just arrived and I assumed it 
was November, sorry. 


- Tom 


Tom McDermott 
mcdermot@aud.alcatel.com 


From mcdermot@rdxsunhost.aud.alcatel.com Thu Nov 07 13:23:42 1996 
Received: from aud.alcatel.com (rockdal.aud.alcatel.com [128.251.30.1]) by 
tapr.org (8.7.5/8.7.3/1.9) with SMTP id NAA20152 for <hfsig@tapr.org>; Thu, 7 Nov 
1996 13:23:41 -0600 (CST) 
Received: from rdxsunhost.aud.alcatel.com.Aud.Alcatel.COM by aud.alcatel.com (4.1/ 
SMI-4.1) 
id AAQ2454; Thu, 7 Nov 96 13:23:39 CST 
Received: from eagle.aud.alcatel.com by rdxsunhost.aud.alcatel.com.Aud.Alcatel.COM 
(4.1/SMI-4.1) 
id AA23101; Thu, 7 Nov 96 13:23:38 CST 
Received: by eagle.aud.alcatel.com (4.1/SMI-4.1) 
id AAQ3471; Thu, 7 Nov 96 13:23:37 CST 
Date: Thu, 7 Nov 96 13:23:37 CST 
From: mcdexrmot@rdxsunhost.aud.alcatel.com (Tom Mcdermott) 
Message-Id: <9611071923 .AAQ3471@eagle.aud.alcatel.com> 
To: hfsig@tapr.org 
Subject: Re: [HFSIG:1695] 


> Am I missing something here or are we talking about training sequencies, 
> if so HF serial tone modems use this technique combined with 

> decision directed equalisation to update their adaptive equalisers. 

> 


Charles G4GUO 


VvVV 


I guess it depends on the definition of 'training'. I sort 
of assume that training applies to time before any data gets sent, 
while PSAM applies the symbols interleaved with the data so that 


variations in the channel response with time can be tracked out. 

In land-line modems, the training time lets the adaptive equalizers 
adapt to the channel, but if the channel varies too much and too 
quickly after the data has started, the adaption cannot keep up, 
and they lose it. Normally not a problem with land-lines, but 
perhaps an issue with HF. 


- Tom 


Tom McDermott 
mcdermot@aud.alcatel.com 


From mcdermot@rdxsunhost.aud.alcatel.com Thu Nov 07 13:29:47 1996 
Received: from aud.alcatel.com (rockdal.aud.alcatel.com [128.251.30.1]) by 
tapr.org (8.7.5/8.7.3/1.9) with SMTP id NAA20469 for <hfsig@tapr.org>; Thu, 7 Nov 
1996 13:29:45 -0600 (CST) 
Received: from rdxsunhost.aud.alcatel.com.Aud.Alcatel.COM by aud.alcatel.com (4.1/ 
SMI-4.1) 
id AAQ2739; Thu, 7 Nov 96 13:29:42 CST 
Received: from eagle.aud.alcatel.com by rdxsunhost.aud.alcatel.com.Aud.Alcatel.COM 
(4.1/SMI-4.1) 
id AA23257; Thu, 7 Nov 96 13:29:41 CST 
Received: by eagle.aud.alcatel.com (4.1/SMI-4.1) 
id AAQ3477; Thu, 7 Nov 96 13:29:41 CST 
Date: Thu, 7 Nov 96 13:29:41 CST 
From: mcdexrmot@rdxsunhost.aud.alcatel.com (Tom Mcdermott) 
Message-Id: <9611071929 .AA03477@eagle.aud.alcatel.com> 
To: hfsig@tapr.org 
Subject: Re: [HFSIG:1694] Amplitude calibration 


It sounds like a very interesting idea. One variation would be the 
following: Rather than sending a periodic known symbol, scramble the 
input data with a known pseudo-random sequence. That would guarantee 
that all possible symbol states occur at approximately equal rates. 
Then you could use AGC in the receiver to compensate for fading. 


The AGC time constant would have to be long enough to integrate enough 
symbols to obtain a good average amplitude. But the time constant would 
also have to be short with respect to the fastest fade times. I suspect 
that typical values used in HF SSB receivers would be about right, since 
they have the same bandwidth ("data rate") and fading constraints. 


A similar problem exists with the periodic-symbol approach -- the known 
symbol must occur much more often than the fade time, but not so often 
that it affects throughput. 


A third variation would be to use both techniques together. Scrambling 
would allow receiver AGC to keep the input to the demodulator at the 


VV VV VV VV VV VV VV VV VV 


> optimum level for best dynamic range, while the periodic known symbol 
> would allow the demod to dial in a fine amplitude adjustment. 

> 

> Alan Bloom N1AL 

> 

> 


Alan: interesting idea. There are some differences in 
performance I think. Suitably scrambled data would let you 
recover phase and amplitude, any QAM modem has to do that. 
You are restricted to being required to be able to differentiate 
adjacent constellation points. In the PSAM article, adacent 
constellation points could not be distuingished. So the PSAM 
symbols, being known a priori, let one derive the channel response 
almost exactly even if individual constellation points are not visible. 


It was amazing to me that a single ‘blob' of a constellation 
could be resurrected into 16 nice constellation points just by 
dividing by the computed channel response. 


- Tom 


Tom McDermott 
mcdermot@aud.alcatel.com 


From chbrain@dircon.co.uk Thu Nov 07 14:33:42 1996 
Received: from felix.dircon.co.uk (felix.dircon.co.uk [193.128.224.10]) by 
tapr.org (8.7.5/8.7.3/1.9) with SMTP id OAA24469 for <hfsig@tapr.org>; Thu, 7 Nov 
1996 14:33:38 -0600 (CST) 
Received: by felix.dircon.co.uk id AA20646 
(5.67b/IDA-1.5 for <hfsig@tapr.org>); Thu, 7 Nov 1996 20:15:00 GMT 
Received: from gw2-172.pool.dircon.co.uk(194.112.35.172) by amnesiac via smap 
(V1.3) 
id sma020633; Thu Nov 7 20:14:43 1996 
Message-Id: <1.5.4.32.19961107201015 .0067dd78@popmail.dircon.co.uk> 
X-Sender: chbrain@popmail.dircon.co.uk 
X-Mailer: Windows Eudora Light Version 1.5.4 (32) 
Mime-Version: 1.0 
Content-Type: text/plain; charset="us-ascii" 
Date: Thu, 07 Nov 1996 20:10:15 +0000 
To: hfsig@tapr.org 
From: Charles Brain <chbrain@dircon.co.uk> 
Subject: Re: [HFSIG:1697] Re: 


At 13:27 07/11/96 -0600, you wrote: 

> 

>> Am I missing something here or are we talking about training sequencies, 
>> if so HF serial tone modems use this technique combined with 

>> decision directed equalisation to update their adaptive equalisers. 


>> 


>> 

>> Charles G4GUO 

>> 

> 

> I guess it depends on the definition of 'training'. I sort 


>of assume that training applies to time before any data gets sent, 
Sorry retraining ! 


You want to ask Harris how they do the equalisation on their serial 
tone modems. 


> Normally not a problem with land-lines, but perhaps an issue with HF. 
> 
There's the rub. 


>- Tom 
73 Charles 


From alanb@polecat.sr.hp.com Thu Nov 07 16:24:12 1996 

Received: from relay.hp.com (relay.hp.com [15.255.152.2]) by tapr.org 

(8.7.5/8.7.3/1.9) with ESMTP id QAA00422 for <hfsig@tapr.org>; Thu, 7 Nov 1996 

16:24:09 -0600 (CST) 

Received: from srmail.sr.hp.com by relay.hp.com with ESMTP 
(1.37.109.16/15.5+ECS 3.3) id AA260575436; Thu, 7 Nov 1996 14:23:57 -0800 

Received: from polecat.sr.hp.com (algae.sr.hp.com) by srmail.sr.hp.com with ESMTP 
(1.37.109.16/15.5+ECS 3.3) id AA116795435; Thu, 7 Nov 1996 14:23:56 -0800 

Received: by polecat.sr.hp.com 
(1.37.109.16/15.5+ECS 3.3) id AAQ62285434; Thu, 7 Nov 1996 14:23:55 -0800 

From: Alan Bloom <alanb@polecat.sr.hp.com> 

Message-Id: <199611072223 .AA062285434@polecat.sr.hp.com> 

Subject: Amplitude Calibration 

To: hfsig@tapr.org 

Date: Thu, 7 Nov 1996 14:23:54 -0800 (PST) 

X-Mailer: ELM [version 2.4 PL21] 

Mime-Version: 1.0 

Content-Type: text/plain; charset=US-ASCII 

Content-Transfer-Encoding: 7bit 


mcdermot@rdxsunhost.aud.alcatel.com (Tom Mcdermott) wrote: 


>> It sounds like a very interesting idea. One variation would be the 
>> following: Rather than sending a periodic known symbol, scramble the 
>> input data with a known pseudo-random sequence. That would guarantee 
>> that all possible symbol states occur at approximately equal rates. 
>> Then you could use AGC in the receiver to compensate for fading. 


> Alan: interesting idea. There are some differences in 
>performance I think. Suitably scrambled data would let you 
>recover phase and amplitude, any QAM modem has to do that. 

>You are restricted to being required to be able to differentiate 


>adjacent constellation points. In the PSAM article, adacent 
>constellation points could not be distuingished. So the PSAM 

>symbols, being known a priori, let one derive the channel response 
>almost exactly even if individual constellation points are not visible. 


So the periodic known symbol is used to recover phase as well as 
amplitude information? Many QPSK systems use differential modulation 
(where the data bits determine the transitions between symbol states, 
rather than the states themselves) to get around the phase ambiguity 
problem; PSAM would eliminate that requirement. Scrambling at the 
bit rate would not do anything to recover absolute phase information. 
Another reason why using PSAM and scrambling together might be a 
synergistic solution. 


> It was amazing to me that a single 'blob' of a constellation 
>could be resurrected into 16 nice constellation points just by 
>dividing by the computed channel response. 


The clock recovery circuitry in a normal QPSK or QAM detector should 
deal with any variations in the phase of the input signal. It seems 
like the main advantage of PSAM (or scrambling) is that it can take 
out the amplitude variations as well. 


Alan Bloom N1AL 


From karn@qualcomm.com Thu Nov 07 16:34:17 1996 

Received: from warlock.qualcomm.com (warlock.qualcomm.com [129.46.52.129]) by 
tapr.org (8.7.5/8.7.3/1.9) with ESMTP id QAAQ0828 for <hfsig@tapr.org>; Thu, 7 Nov 
1996 16:34:15 -0600 (CST) 

Received: from servo.qualcomm.com (servo.qualcomm.com [129.46.101.170]) by 
warlock.qualcomm.com (8.7.5/1.3/8.7.2/1.12) with ESMTP id OAA04888 for 
<hfsig@tapr.org>; Thu, 7 Nov 1996 14:32:56 -0800 (PST) 

Received: (from karn@localhost) by servo.qualcomm.com (8.7.5/1.0/8.7.2/1.9) id 
0AA19910; Thu, 7 Nov 1996 14:24:34 -@800 (PST) 

Date: Thu, 7 Nov 1996 14:24:34 -0800 (PST) 

From: Phil Karn <karn@qualcomm.com> 

Message-Id: <199611072224 .0AA19910@servo.qualcomm. com> 

To: Thomas Sailer <sailer@ife.ee.ethz.ch> 

CC: hfsig@tapr.org 

In-reply-to: <327EQE03.2783@ife.ee.ethz.ch> (message from Thomas Sailer on Mon, 4 
Nov 1996 09:40:55 -0600 (CST)) 

Subject: Re: [HFSIG:1690] Re: DSP/Modem article 


Thomas, 


Thanks for your comments. They obviously come from somebody with a lot 
of practical experience. Some questions of my own: 


>1. Bad analog section of many soundcards. Frequency response 
>and/or noise leaves much to be desired. 


I agree few cards really make it to CD-quality, but is this really a 
problem? I'd expect the radio and the channel to still be the limiting 


factors. 


>2. Low resolution or sampling rates are still common. SBPro 
>can't do 16bits! WSS cards are somehow better... 


Again, is this really a problem? Perhaps you can't xtotally* ignore 
your AF gain setting, but the achievable dynamic range should make it 
pretty non-critical, at least with a 16-bit card. 


BTW, in Qualcomm CDMA we routinely use 4-bit A/Ds. Analog gain 
controls up front bring the signal into the limited dynamic range of 
the A/Ds, which is about 24 dB. That roughly matches the processing 
gain of the system, and it's plenty for an efficient coded modulation 
method. 


>3. A garden variety of "almost compatible" soundcards makes 
>life hard. Even Creative's Cards aren't fully backwards 
>compatible 


Yeah, tell me about it. When I wrote my own sound driver for KA9Q NOS, 
I decided to support only the SB16. I didn't consider 8-bit support to 
be very important since the SB16 was already pretty cheap and seems to 
have become the de-facto standard. Everybody seems to be upgrading to 
them anyway, to get good quality game audio if nothing else. 


>4. Full duplex cards are still the exception. Creative's 


True, but this is not a problem with half-duplex radios. Yeah, to do 
digital speech you'll need a second card for the speaker/microphone, 
though. Too bad it's not possible to put one SB16 channel in receive 
and the other in transmit. 


>5. You cannot usually use the OS driver for the soundcard. 


Why is this? Buffer draining delays? Can the OS buffer size be 
configured? 


>6. It is very nontrivial to attach a time tag to each sample, 


Yeah, I can believe this. One hack might be to tune to WWV to 
calibrate both the absolute time and the sample rate. If you have good 
low frequency response in the radio you can decode the 100 Hz data 
stream and set the PC clock at the same time. But just doing an 
autocorrelation on the data sequence ought to bring out the second 
ticks and give you a pretty good idea of the sampling rate. 


Question: do the soundcards typically maintain their sampling rate 
once you know what it is? I note that the clock in my Pentium loses a 
very consistent ~7 seconds per day, which tells me that although the 
oscillator is off frequency, it's pretty stable. 


>7. There is not one common sampling frequency every soundcard 
>can produce, i.e. every brand of soundcard seems to have 


>a distinct set of sampling frequencies available. 


What are these for the SB16? The documentation implies that you can 
set an almost continuous range of sample rates. 


Phil 


From sailer@ife.ee.ethz.ch Fri Nov 08 03:44:37 1996 

Received: from ife.ee.ethz.ch (root@ife-ifel.ee.ethz.ch [129.132.25.65]) by 
tapr.org (8.7.5/8.7.3/1.9) with ESMTP id DAAQ1303 for <hfsig@tapr.org>; Fri, 8 Nov 
1996 03:44:24 -0600 (CST) 

Received: from eldrich.ee.ethz.ch (sailer@eldrich.ee.ethz.ch [129.132.25.145]) by 
ife.ee.ethz.ch (8.8.2/8.8.2) with SMTP id KAA26271; Fri, 8 Nov 1996 10:44:09 +0100 
(MET) 

Sender: sailer@ife.ee.ethz.ch 

Message-ID: <328300E8.1F83@ife.ee.ethz.ch> 

Date: Fri, 08 Nov 1996 10:44:08 +0100 

From: Thomas Sailer <sailer@ife.ee.ethz.ch> 

Organization: IfE 

X-Mailer: Mozilla 3.0 (X11; I; SunOS 5.5 sun4m) 

MIME-Version: 1.0 

To: hfsig@tapr.org 

CC: karn@qualcomm.com 

Subject: Re: [HFSIG:1701] Re: DSP/Modem article 

References: <199611072224 .0AA19910@servo.qualcomm. com> 

Content-Type: text/plain; charset=us-ascii 

Content-Transfer-Encoding: 7bit 


>1. Bad analog section of many soundcards. Frequency response 
>and/or noise leaves much to be desired 

I agree few cards really make it to CD-quality, but is this really a 
problem? I'd expect the radio and the channel to still be the limiting 
> factors. 

Frequency response definitely _is_ a problem. Look at measurements 
done by for example the c't magazine. On my laptop, I cannot monitor 
G3RUH 9k6 transmissions, due to frequency response problems. 

Some soundcards have a built in and not bypassable AGC, which 

wreaks havoc (SBPro clones such as ESS). 

Furthermore, some soundcards (SB32, presumably also SB16) have 

a not bypassable analog "equalizer" filter at the output, which can 
induce unknown phase distortions. (When we tried G3RUH FSK, the 

best setting of these filter was _not_ what Creative said it was 

the OdB setting) 

SB cards have 3 settings for the anti aliasing filter: 3.2kHz, 

8.8kHz or off. This is simply not adequate. 


VVV MV 


>2. Low resolution or sampling rates are still common. SBPro 

>can't do 16bits! WSS cards are somehow better...> 

Again, is this really a problem? Perhaps you can't *xtotally* ignore 
your AF gain setting, but the achievable dynamic range should make it 
pretty non-critical, at least with a 16-bit card. 

BTW, in Qualcomm CDMA we routinely use 4-bit A/Ds. Analog gain 
controls up front bring the signal into the limited dynamic range of 


VV VV VV MV 


> the A/Ds, which is about 24 dB. That roughly matches the processing 
> gain of the system, and it's plenty for an efficient coded modulation 
> method. 

That depends on the system and the signal conditionig prior to the 
A/D converter. 

A few years ago when I played with my RTTY decoders, the 8bit 
soundcard version performed poorly compared to the TI DSK version 
(14bit A/D). On HF, if you want to do part of the filtering 
digitally, it requires much more than 8 bit resolution. 

If you had an analoguely filtered and gain controlled signal, 

8bit would be enough, but you presumably would not want to do that, 
because good (read with a constant group delay) analog filters 

are _extremely_ expensive. 

BTW note that the gain controllable amplifier should be controlled 

by the demodulator! When I did some experiments with heavily coded 
low speed DPSK on HF, week signal performance was often much better 
when I turned off the transceivers AGC and adjusted by myself. 

AGC circuits of contemporary HF transceivers may be adequate for 

SSB, but aren't for digital modes. 


>3. A garden variety of "almost compatible" soundcards makes 
>life hard. Even Creative's Cards aren't fully backwards 
>compatible> 


Yeah, tell me about it. When I wrote my own sound driver for KA9Q NOS, 
I decided to support only the SB16. I didn't consider 8-bit support to 
be very important since the SB16 was already pretty cheap and seems to 


have become the de-facto standard. Everybody seems to be upgrading to 
them anyway, to get good quality game audio if nothing else. 

Well, here I do not agree. I even got questions that wondered why 

my 9k6 RUH driver does not work with SB2! SBPro is still much more 
common than SB16. Anyway I quite dislike SB, see my above comments 

on the analog section of the card. 

Creative tells us that the only way to do "high speed" (read above 
13kSamples/s) AD on SBPro is the highspeed dma command, which 
according to creative's SDK does not exist on SB DSP 4 (SB16 and SB32). 
SB DSP 4 however has different commands for 8bit DMA, which in 

turn do not work on SBPro. 

However, when I lately tried the highspeed dma commands on an SB32, 

it seemed to work. But this is guesswork... 


VVVV VV VV 


> >4. Full duplex cards are still the exception. Creative's 

> 

> True, but this is not a problem with half-duplex radios. Yeah, to do 
Oh yes it is. If full duplex would be common, I would have done 

some HF modes (Amtor,Pactor) already some time ago. It would make 
these HF things much easier. 


> >5. You cannot usually use the OS driver for the soundcard. 

> Why is this? Buffer draining delays? Can the OS buffer size be 
> configured? 

As long as you're only receiving (or only transmitting :-)) 

there is no problem using the OS drivers. But as soon as you'll 
have to switch transmission directions in the 10ms region, you're 


on your own. 

Under Linux, you cannot normally reduce the buffer size to a reasonnably 
low value. There is however a method to specify and map the DMA 
buffer into the applications address space, but this API is very 
complex. And besides, this requires that your process gets scheduled 
immediately, which is at least not the case with the 'interactive' 
scheduler that is the default. Maybe this works with the realtime 
(POSIX.1b) extensions (sched_setscheduler), but I have to admit that 
I haven't tried it. 

Under Windows, the only way to do rather low delay sound output seems 
to be DirectSound, which cannot do sound input. 


>6. It is very nontrivial to attach a time tag to each sample, 


Yeah, I can believe this. One hack might be to tune to WWV to 
calibrate both the absolute time and the sample rate. If you have good 
low frequency response in the radio you can decode the 100 Hz data 
stream and set the PC clock at the same time. But just doing an 
autocorrelation on the data sequence ought to bring out the second 
ticks and give you a pretty good idea of the sampling rate. 

Is this 100Hz data stream modulated onto WWV? and how? 

Of course there are methods to measure the sampling rate, 

but how are you going to tell Joe Ham how he should do it? 

Too bad if he does not own an HF radio (maybe he only wants to 

do VHF/UHF) or happens to live outside the US... My neighbors 

at least would definitely not like it if I built an antenna 

capable of receiving WWV over here in Europe :-) 

(you could say that there's DCF77 here in Europe, but there were 
rumours that DCF77 would be shut down in favor of a satellite 

TV subcarrier system... ok, one could also use the TV line frequency 
as a reference signal) 


VVVVVV VV 


> Question: do the soundcards typically maintain their sampling rate 

> once you know what it is? I note that the clock in my Pentium loses a 
> very consistent ~7 seconds per day, which tells me that although the 
> oscillator is off frequency, it's pretty stable. 

I haven't temperature cycled my soundcards yet, but I besides 

this the sampling rate should be stable. 


>7. There is not one common sampling frequency every soundcard 

>can produce, i.e. every brand of soundcard seems to have 

>a distinct set of sampling frequencies available.> 

What are these for the SB16? The documentation implies that you can 
set an almost continuous range of sample rates. 

Well yes, according to the documentation, SB16 should be capable of 
any integer frequency sampling rate. But I do not own one, so I cannot 
tell anything about it. Besides, implementing such a codec having 
decent analog performance is not so easy, and since I'm not impressed 
by creative's engineering capabilities, I'm rather sceptical. 

There are ‘continuous rate’ codecs by Analog Devices and probably 
also by Crystal Semi, and since these firms know their business, 

I assume their devices will perform as expected, but with creative... 


VVVV WV 


I'm only talking about the sample I/O capabilities of soundcards, 
other systems, such as the FM synthesizer, are IMHO of little 

value to implementing communications systems. 

IMHO WSS soundcards are usually better than Soundblaster and 
compatible, since their main chip is an almost complete 

and good soundcard on-a-chip by Analog Devices or Crystal Semi, 

so card makers cannot do too much the wrong way. 

And these two companies have a tradition and many years of experience 
in the quality codec business. Creative's Chipsets on the other hand 
leave much to be desired, especially in the audio section. 


Tom 


From karn@laptop Sat Nov 09 00:14:13 1996 
Received: from laptop (ra4000-p38.qualcomm.com [129.46.54.118]) by tapr.org 
(8.7.5/8.7.3/1.9) with SMTP id AAA28212 for <hfsig@tapr.org>; Sat, 9 Nov 1996 
00:14:10 -0600 (CST) 
Received: by laptop 
id mOvKd0i-000MG3C 
(Debian /\oo/\ Smail3.1.29.1 #29.37); Mon, 4 Nov 96 20:21 PST 
Message-Id: <mOvKd0i-Q00MG3C@laptop> 
Date: Mon, 4 Nov 96 20:21 PST 
From: Phil Karn <karn@laptop> 
To: hfsig@tapr.org 
Reply-To: karn@qualcomm.com 
In-reply-to: <9611062058.AA03299@eagle.aud.alcatel.com> 
(mcdermot@rdxsunhost.aud.alcatel.com) 
Subject: Re: [HFSIG:1692] PSAM (IEEE Comm, Nov '96) 


Tom, 


This "PSAM" stuff sounds an awful lot like training an equalizer ona 
periodic known data pattern. And yes, this is a well known and widely 
practiced approach to HF data, at least with high performance commercial 
and military modems. 


Phil 


From forrerj@peak.org Wed Nov 13 16:20:50 1996 

Received: from PEAK.ORG (forrerj@PEAK.ORG [198.68.22.17]) by tapr.org 
(8.7.5/8.7.3/1.9) with SMTP id QAA26399 for <HFSIG@TAPR.ORG>; Wed, 13 Nov 1996 
16:20:48 -0600 (CST) 

Received: (from forrerj@localhost) by PEAK.ORG (8.6.13/8.6.7) id OAA09996; Wed, 13 
Nov 1996 14:20:56 -0800 

Date: Wed, 13 Nov 1996 14:20:56 -0800 (PST) 

From: Johan Forrer <forrerj@peak.org> 

X-Sender: forrerj@kira 

To: HFSIG@tapr.org 

Subject: Implications of SFDR 

Message-ID: <Pine.SUN.3.91.961113140702 .7926A-100000@kira> 

MIME-Version: 1.0 

Content-Type: TEXT/PLAIN; charset=US-ASCII 


Hi all, 


Could someone please help me grasp the implications of "spurious free 
dynamic range" (SFDR). 


1) Dealing with say a band © - 20 MHz wide, a pair of signals, 
one at say 9.5 MHz, the other at 10 MHz, where one signal is 
significantly stronger than the other. 


2) Dealing with limited number of A/D quatisation levels. What is the 
nature of the noise model?, i.e., band limited, autoregressive, or 
whatever? 


3) Does oversampling and decimation have any benifits here, i.e., if 
the A/D convertor could sample a 1 GSPS but have only 3 bits of 
resolution - what is that worth with respect to effective SFDR. 


Perhaps you would recognize that these questions relate to working 
with DSP at RF rates, i.e., connecting the A/D convertor to the antenna 
and hope for the best :-). 


Comments, suggestions or discussion would be most helpful. 
Thanks much, 
--Johan, KC7WW 


From 100577.1452@CompuServe.COM Thu Nov 14 14:11:59 1996 
Received: from dub-img-7.compuserve.com (dub-img-7.compuserve.com 
[149.174.206.137]) by tapr.org (8.7.5/8.7.3/1.9) with SMTP id OAA23906 for 
<HFSIG@tapr.org>; Thu, 14 Nov 1996 14:11:57 -0600 (CST) 
Received: by dub-img-7.compuserve.com (8.6.10/5.950515) 
id PAA26662; Thu, 14 Nov 1996 15:11:26 -0500 
Date: 14 Nov 96 15:09:02 EST 
From: Mike Kerry <100577.1452@CompuServe.COM> 
To: "(unknown)" <HFSTG@tapr.org> 
Subject: Designing Filters 
Message-ID: <961114200901_100577.1452 GHW117-1@CompuServe. COM> 


I am experimenting with designing FIR filters 

for HF data modes (aren't we all?) and would be 

interested to hear some opinions about the important 
features to be considered, e.g:- 

- Blackman vs Kaiser vs other windowing functions 

- choice of passband width, relating to shift and Baud rate 


- perhaps stop-band width is more important than pass-band? 


- length of filter, especially considering the effect on ISI 


- what else? 
Thanks, 
Mike Kerry, G4BMK 


From alanb@polecat.sr.hp.com Thu Nov 14 17:38:08 1996 

Received: from relay.hp.com (relay.hp.com [15.255.152.2]) by tapr.org 

(8.7.5/8.7.3/1.9) with ESMTP id RAAQ1774 for <hfsig@tapr.org>; Thu, 14 Nov 1996 

17:38:03 -0600 (CST) 

Received: from srmail.sr.hp.com by relay.hp.com with ESMTP 
(1.37.109.16/15.5+ECS 3.3) id AAQ54974674; Thu, 14 Nov 1996 15:37:55 -0800 

Received: from polecat.sr.hp.com (algae.sr.hp.com) by srmail.sr.hp.com with ESMTP 
(1.37.109.16/15.5+ECS 3.3) id AA184654673; Thu, 14 Nov 1996 15:37:54 -0800 

Received: by polecat.sr.hp.com 
(1.37.109.16/15.5+ECS 3.3) id AAQ95324672; Thu, 14 Nov 1996 15:37:53 -0800 

From: Alan Bloom <alanb@polecat.sr.hp.com> 

Message-Id: <199611142337 .AA095324672@polecat.sr.hp.com> 

Subject: Spurious-Free Dynamic Range 

To: hfsig@tapr.org 

Date: Thu, 14 Nov 1996 15:37:52 -0800 (PST) 

X-Mailer: ELM [version 2.4 PL21] 

Mime-Version: 1.0 

Content-Type: text/plain; charset=US-ASCII 

Content-Transfer-Encoding: 7bit 


Johan Forrer <forrerj@peak.org> wrote: 


>Could someone please help me grasp the implications of "spurious free 
>dynamic range" (SFDR). 


SFDR is defined as the ratio (usually expressed in dB) between the RMS 
value of the input signal and the RMS value of the largest spurious 
frequency component. The value depends on the signal waveform, usually 
a full-scale sine wave. It gets worse the higher the frequency. 

If the signal consists of two sine waves, the test is usually called 
"two-tone intermodulation distortion" (two-tone IMD) rather than SFDR. 


>1) Dealing with say a band © - 20 MHz wide, a pair of signals, 
> one at say 9.5 MHz, the other at 10 MHz, where one signal is 
> Significantly stronger than the other. 


Data sheet IMD specs assume the two signals are of equal amplitude. 
With many analog components, you can assume that third-order spurs 
fall 3 dB per dB of the input signal, fifth order spurs fall 5 dB per 
dB, etc. But that's not true for A/D converters. Sometimes the spur 
actually gets stronger at lower signal levels. 


>2) Dealing with limited number of A/D quatisation levels. What is the 
> nature of the noise model?, i.e., band limited, autoregressive, or 


> whatever? 


As you probably know, SFDR measures only spurs, not quantization noise. 


Signal-to-noise ratio (SNR) in dB is theoretically 6*(bits resolution) 
+ 1.76 dB. So a 12-bit A/D theoretically has 73.76 dB SNR. Practical 
devices are typically somewhat worse than that. 


The noise is white, uniformly spread between 0 Hz and the Nyquist 
frequency. If you look at the spectrum using a 1024-point FFT, the 
noise will appear 10*log(1024) = 30 dB lower since each frequency 
point represents only 1/1024 of the total quantization noise. 


>3) Does oversampling and decimation have any benifits here, i.e., if 
> the A/D convertor could sample a 1 GSPS but have only 3 bits of 
> resolution - what is that worth with respect to effective SFDR. 


With 3 bits of resolution, the SNR is theoretically 19.76 dB, spread 
out between 0 and 500 MHz. If you decimated and filtered down to 

30 MHz, that would improve the SNR to 19.76 + 10*log(500/30) = 32 dB. 
Usually, what people do is use delta-sigma A/D converters designed 
to shape the noise spectrum to be non-white. If most of the noise 
is pushed up in frequency, then the low-pass decimation filters can 
get rid of most of it and you end up with much better SNR. 


>Perhaps you would recognize that these questions relate to working 
>with DSP at RF rates, i.e., connecting the A/D convertor to the antenna 
>and hope for the best :-). 


Just in the last few months, new A/D converters have been introduced 
by Analog Devices that make direct sampling of an entire RF band 
practical. However, they are designed for cellular applications, 
where the in-band signals are well controlled. That is, unlike the 

HF amateur bands, all the signals have similar power levels, and there 
are a limited number of them (<= the number of channels). You still 
need a tuned RF front end to eliminate out-of-band signals. As I 
understand it, these new A/Ds are just barely good enough even under 
these relatively benign conditions. They are used in base-station 
designs, where price is not much of an issue. 


To see what the A/D is up against, consider the US cellular band, 
which consists of 832 channels between 869 and 894 MHz. I think 
each A/D only has to deal with one subband ("A" band or "B" band), 
which consists of 333 channels spaced 30 kHz apart. If each of 
the incoming 333 signals were exactly the same power level, then 
the total signal seen by the A/D would have a 10*log(333) = 25 dB 
peak-to-average ratio. But of course, all the signals are not 
exactly the same. And the absolute level is not all that well 
controlled. Unlike analog components, an A/D does not degrade 
gracefully when the input gets too strong -- once you exceed the 
input rails, severe distortion results. For both those reasons 
you need to leave lots of headroom; let's say another 20 dB or so. 
That puts your signal level down around -45 dB from full scale. 


The two-tone IMD spec is not too useful in this application, since 
there are up to 333 tones to deal with. There are many combinations 
of third, fifth, seventh, etc. order products from other channels 


that can produce a spur in a given channel. Two in-phase, 
equal-amplitude spurs together are 6 dB more powerful than either 
spur alone. Counting third-order products only, any channel will 
see 166 spurs from the other 332 channels. The total worst-case 
spur level would then be up to 20x1lo0g(167) = 44 dB stronger than 
from a single third-order intermod. 


So we're talking on the order of 90 dB SFDR for the A/D. And as I 
recall, cellular equipment manufacturers are looking for numbers 
even a little better than that. That's right at the state of the 
art in A/D design. 


To cover an amateur HF band, I think even more performance would be 
called for. For one thing, there can be more than 333 signals on 
the band at one time. For another, the signal levels vary all over 
the map. You may wish to listen to a signal just above the noise 
level (around -130 dBm or so) at the same time as a contest is going 
on with multiple S9+40 dB (~-30 dBm) signals at the other end of the 


band. You would have to adjust the RF gain so that full scale on 
the A/D is on the order of 0 dBm at the antenna terminals. That 
implies a SFDR around 130 cB. 


And that's for a single band. It would get worse if you wanted to 
cover 0-30 MHz in one fell swoop. 


In addition to spurs, quantization noise would be a problem. 
Assuming a 16-bit A/D with 90 dB SNR, and a ratio of Nyquist 
frequency to bandwidth of (500/3), the quantization noise ina 
3 kHz channel would be around -112 dBm, or nearly 20 dB louder 
than the signal you are trying to hear. 


Still, that's a lot closer to acceptable performance than existed 
a year ago. In years to come, as A/D performance improves and 
prices fall, we may yet get all-digital radios with performance 
equal to the best analog designs. 


Alan Bloom N1AL 


From alanb@polecat.sr.hp.com Thu Nov 14 20:59:01 1996 
Received: from hp.com (hp.com [15.255.152.4]) by tapr.org (8.7.5/8.7.3/1.9) with 
ESMTP id UAAQ9629 for <hfsig@tapr.org>; Thu, 14 Nov 1996 20:58:58 -Q600 (CST) 
Received: from srmail.sr.hp.com by hp.com with ESMTP 
(1.37.109.16/15.5+ECS 3.3) id AAQ43626735; Thu, 14 Nov 1996 18:58:55 -0800 
Received: from polecat.sr.hp.com (algae.sr.hp.com) by srmail.sr.hp.com with ESMTP 
(1.37.109.16/15.5+ECS 3.3) id AA213906734; Thu, 14 Nov 1996 18:58:54 -0800 
Received: by polecat.sr.hp.com 
(1.37.109.16/15.5+ECS 3.3) id AA233916733; Thu, 14 Nov 1996 18:58:53 -0800 
From: Alan Bloom <alanb@polecat.sr.hp.com> 
Message-Id: <199611150258 .AA233916733@polecat.sr.hp.com> 
Subject: FIR filters 
To: hfsig@tapr.org 
Date: Thu, 14 Nov 1996 18:58:53 -0800 (PST) 


X-Mailer: ELM [version 2.4 PL21] 
Mime-Version: 1.0 

Content-Type: text/plain; charset=US-ASCII 
Content-Transfer-Encoding: 7bit 


Mike Kerry <100577.1452@compuserve.com> wrote: 


>I am experimenting with designing FIR filters 

>for HF data modes (aren't we all?) and would be 

>interested to hear some opinions about the important 
>features to be considered, e.g:- 

> 

>- Blackman vs Kaiser vs other windowing functions 

> 

>- choice of passband width, relating to shift and Baud rate 
> 

>- perhaps stop-band width is more important than pass-band? 
> 

>- length of filter, especially considering the effect on ISI 
> 

>- what else? 


One important feature is a Nyquist response. A Nyquist filter is 

one where the signal trajectory passes exactly through the proper 
symbol location exactly at each decision time. This is true no matter 
what values nearby symbols take. i.e. there is no inter-symbol 
interference (ISI). 


One common Nyquist filter is the "Raised-Cosine." The frequency 
response is unity from zero Hz up to (1-alpha) times the cutoff 
frequency and zero from (1+alpha) * Fc up to the Nyquist rate. 
(Alpha is a selectable parameter that determines how sharply the 
filter cuts off.) Between (1-alpha)*Fc and (1+alpha)«*Fc, the 
frequency response is half of a raised cosine (surprise!): 


SSScre tot sete Sts Frequency 
alpha-->| |<-- 
| | | 


-->| |<--alpha 


That's the frequency response. The impulse response in the time domain 
is a weighted sinc function. sinc(x) = (sine(PI*x))/(PI*x) Note that 
sinc(x) is zero for all non-zero integer values of x. That means that 
an impulse (one symbol) has zero effect on adjacent symbols, so there 
is no inter-symbol interference. 


You need a filter both in the transmitter (to reduce adjacent-channel 
interference) and in the receiver (to reject nearby signals). Two 
Nyquist filters in series are no longer Nyquist. So what is normally 
done is to use a "root-Nyquist" filter such as the root-raised-cosine 
filter, whose frequency response is the square root of a raised-cosine. 
In this way, the total channel response is Nyquist, so there is no net 
inter-symbol interference. Note that the actual transmitted signal has 
lots of inter-symbol "interference." It is only after passing through 
the matched filter in the receiver that the ISI is magically removed. 


By the way, in order to have a Nyquist response, the cut-off frequency 
Fe (-3 dB point for root-Nyquist, -6 dB for Nyquist) should be at 
exactly 1/2 the symbol rate. 


It is possible to use non-Nyquist filters so long as the resulting 
inter-symbol interference is kept small enough not to cause a problem. 
That's what is done for GMSK. Gaussian Minimum-Shift Keying uses a 
(surprise!) Gaussian filter which is non-Nyquist. Commercial systems 
that use GMSK include GSM (European digital cellular) and DECT (a 
digital cordless phone standard.) 


The filter coefficients in an FIR filter are the same as the impulse 
response. Since a weighted sinc function theoretically extends from 
minus infinity to plus infinity, it is obviously impossible to build a 
perfect FIR raised-cosine filter. (The same is true of just about any 
other filter, including Gaussian.) One solution is just to truncate 
the theoretical response so that it is short enough to fit into your 
hardware. If you do that to a Nyquist filter, it remains Nyquist, 
Since the zero-crossing points remain at the same places. However, it 
does affect the frequency response, especially in the stopband, so you 
will get additional splatter into adjacent channels. The shorter the 
FIR filter length, the worse the interference. It turns out that if 
you "window" the response, rather than truncating it, the stopband 
rejection is improved. 


Windowing means that the coefficients near the edges are gradually 
reduced in amplitude so that there is no abrupt transition between full 
values and the ones that have been set to zero to fit into the available 
filter width. Many different window functions have been invented over 
the years. The Hann window (raised cosine in the time domain) is very 
simple to implement, but only has 30 dB or so of stopband rejection. 
The Hamming window (offset raised cosine) gets down to better than 

-40 dB. The Blackman window uses two superimposed raised cosines of 
different periods and achieves nearly -60 dB. There is a tradeoff 
between stopband and passband performance -- typically the better the 
stopband rejection the worse the passband accuracy. The Kaiser window 
is parameterised -- by selecting the alpha factor you can optimize the 
passband/stopband tradeoff. 


A root-Nyquist filter does not have zero crossings at the adjacent 
symbol locations. When you truncate or window the impulse response, 
inter-symbol interference is created. That's why you don't necessarily 


want the window with the best stop-band response -- the poorer passband 
accuracy degrdades ISI. 


If you want to play around with filters, there are many software programs 
available. I like to use Mathcad, even though it is not specialized 

for this application. You can choose the filter coefficients using your 
favorite window (you have to know the equation for it) or other filter 
design method and do an FFT on the coefficients to obtain the frequency 
response. Or you can enter the desired frequency response and do an 
inverse FFT to obtain the filter coefficients. (Inelegant, but it works!) 


You can also calculate the ISI by RMS-summing the time-response values 
at all adjacent symbol locations. (If it's a root-Nyquist filter, you 
have to convolve it with an "ideal" filter first.) 


I think you can get a copy of Mathcad for around $100 or so. It is useful 
for many things besides designing filters. It is easy to learn and quite 
powerful. I can send a sample FIR filter Mathcad file to anyone interested. 


Alan Bloom N1AL 


From forrerj@peak.org Thu Nov 14 21:54:50 1996 

Received: from PEAK.ORG (root@PEAK.ORG [198.68.22.17]) by tapr.org 
(8.7.5/8.7.3/1.9) with SMTP id VAA12817 for <hfsig@tapr.org>; Thu, 14 Nov 1996 
21:54:48 -Q600 (CST) 

Received: from p04.t0.monrotel.com (p01.tO.monrotel.com [198.68.25.34]) by 
PEAK.ORG (8.6.13/8.6.7) with SMTP id TAAQ8791 for <hfsig@tapr.org>; Thu, 14 Nov 
1996 19:54:47 -0800 

Message-Id: <199611150354 .TAAQ8791@PEAK .ORG> 

X-Sender: forrerj@peak.org 

X-Mailer: Windows Eudora Version 1.4.4 

Mime-Version: 1.0 

Content-Type: text/plain; charset="us-ascii" 

Date: Thu, 14 Nov 1996 19:58:09 -0800 

To: hfsig@tapr.org 

From: forrerj@peak.org (Johan Forrer) 

Subject: Re: [HFSIG:1706] Spurious-Free Dynamic Range 


Alan, 
That was very helpful information - thanks a lot. 


I follow the rationale - one further question. I assume IMD originates from 

a non-linear process somewhere in the chain, not the quatization process; 

that introduces wide-band noise. Am I right? If so, would that imply that if 

we had a perfectly linear A/D convertor, and a no clipping situation, that SFDR 
ratio would become very large? 


The bit about shaping digitization noise for later filtering is quite 
interesting. Do you perhaps a have a reference to how that's done? 


I recently read a paper on a military radio that uses a one-bit A/D to 
sample its 2.5 MHz IF - the high linearity of this A/D attributes to a quoted 


SFDR in excess of 105 dB, which is quite usable 


As I understand things then, what is needed is a very flexible tunable 
bandpass filter ahead of such a A/D. 


--Johan 


>Johan Forrer <forrerj@peak.org> wrote: 

> 

>>Could someone please help me grasp the implications of "spurious free 
>>dynamic range" (SFDR). 

> 

>SFDR is defined as the ratio (usually expressed in dB) between the RMS 
>value of the input signal and the RMS value of the largest spurious 
>frequency component. The value depends on the signal waveform, usually 
>a full-scale sine wave. It gets worse the higher the frequency. 

>If the signal consists of two sine waves, the test is usually called 
>"two-tone intermodulation distortion" (two-tone IMD) rather than SFDR. 
> 

>>1) Dealing with say a band © - 20 MHz wide, a pair of signals, 

>> one at say 9.5 MHz, the other at 10 MHz, where one signal is 

>> Significantly stronger than the other. 

> 

>Data sheet IMD specs assume the two signals are of equal amplitude. 
>With many analog components, you can assume that third-order spurs 
>fall 3 dB per dB of the input signal, fifth order spurs fall 5 dB per 
>dB, etc. But that's not true for A/D converters. Sometimes the spur 
>actually gets stronger at lower signal levels. 

> 

>>2) Dealing with limited number of A/D quatisation levels. What is the 
>> nature of the noise model?, i.e., band limited, autoregressive, or 
>> whatever? 

> 

>As you probably know, SFDR measures only spurs, not quantization noise. 
>Signal-to-noise ratio (SNR) in dB is theoretically 6x(bits resolution) 
>+ 1.76 dB. So a 12-bit A/D theoretically has 73.76 dB SNR. Practical 
>devices are typically somewhat worse than that. 

> 

>The noise is white, uniformly spread between © Hz and the Nyquist 
>frequency. If you look at the spectrum using a 1024-point FFT, the 
>noise will appear 10*«log(1024) = 30 dB lower since each frequency 
>point represents only 1/1024 of the total quantization noise. 

> 

>>3) Does oversampling and decimation have any benifits here, i.e., if 
>> the A/D convertor could sample a 1 GSPS but have only 3 bits of 

>> resolution - what is that worth with respect to effective SFDR. 

> 

>With 3 bits of resolution, the SNR is theoretically 19.76 dB, spread 
>out between © and 500 MHz. If you decimated and filtered down to 

>30 MHz, that would improve the SNR to 19.76 + 10*log(500/30) = 32 dB. 
>Usually, what people do is use delta-sigma A/D converters designed 


>to shape the noise spectrum to be non-white. If most of the noise 
>is pushed up in frequency, then the low-pass decimation filters can 
>get rid of most of it and you end up with much better SNR. 

> 

>>Perhaps you would recognize that these questions relate to working 
>>with DSP at RF rates, i.e., connecting the A/D convertor to the antenna 
>>and hope for the best :-). 

> 

>Just in the last few months, new A/D converters have been introduced 
>by Analog Devices that make direct sampling of an entire RF band 
>practical. However, they are designed for cellular applications, 
>where the in-band signals are well controlled. That is, unlike the 
>HF amateur bands, all the signals have similar power levels, and there 
>are a limited number of them (<= the number of channels). You still 
>need a tuned RF front end to eliminate out-of-band signals. As I 
>understand it, these new A/Ds are just barely good enough even under 
>these relatively benign conditions. They are used in base-station 
>designs, where price is not much of an issue. 

> 

>To see what the A/D is up against, consider the US cellular band, 
>which consists of 832 channels between 869 and 894 MHz. I think 
>each A/D only has to deal with one subband ("A" band or "B" band), 
>which consists of 333 channels spaced 30 kHz apart. If each of 

>the incoming 333 signals were exactly the same power level, then 
>the total signal seen by the A/D would have a 10*1log(333) = 25 dB 
>peak-to-average ratio. But of course, all the signals are not 
>exactly the same. And the absolute level is not all that well 
>controlled. Unlike analog components, an A/D does not degrade 
>gracefully when the input gets too strong -- once you exceed the 
>input rails, severe distortion results. For both those reasons 

>you need to leave lots of headroom; let's say another 20 dB or so. 
>That puts your signal level down around -45 dB from full scale. 

> 

>The two-tone IMD spec is not too useful in this application, since 
>there are up to 333 tones to deal with. There are many combinations 
>of third, fifth, seventh, etc. order products from other channels 
>that can produce a spur in a given channel. Two in-phase, 
>equal-amplitude spurs together are 6 dB more powerful than either 
>spur alone. Counting third-order products only, any channel will 
>see 166 spurs from the other 332 channels. The total worst-case 
>spur level would then be up to 20x1l0g(167) = 44 dB stronger than 
>from a single third-order intermod. 

> 

>So we're talking on the order of 90 dB SFDR for the A/D. And as I 
>recall, cellular equipment manufacturers are looking for numbers 
>even a little better than that. That's right at the state of the 
>art in A/D design. 

> 

>To cover an amateur HF band, I think even more performance would be 
>called for. For one thing, there can be more than 333 signals on 
>the band at one time. For another, the signal levels vary all over 
>the map. You may wish to listen to a signal just above the noise 
>level (around -130 dBm or so) at the same time as a contest is going 


>on with multiple S9+40 dB (~-30 dBm) signals at the other end of the 
>band. You would have to adjust the RF gain so that full scale on 
>the A/D is on the order of 0 dBm at the antenna terminals. That 
>implies a SFDR around 130 dB. 

> 

>And that's for a single band. It would get worse if you wanted to 
>cover 0-30 MHz in one fell swoop. 

> 

>In addition to spurs, quantization noise would be a problem. 
>Assuming a 16-bit A/D with 90 dB SNR, and a ratio of Nyquist 
>frequency to bandwidth of (500/3), the quantization noise in a 

>3 kHz channel would be around -112 dBm, or nearly 20 dB louder 
>than the signal you are trying to hear. 

> 

>Still, that's a lot closer to acceptable performance than existed 
>a year ago. In years to come, as A/D performance improves and 
>prices fall, we may yet get all-digital radios with performance 
>equal to the best analog designs. 

> 

>Alan Bloom N1AL 

> 

> 


From 100577.1452@CompuServe.COM Fri Nov 15 14:45:56 1996 
Received: from hil-img-6.compuserve.com (hil-img-6.compuserve.com 
[149.174.177.136]) by tapr.org (8.7.5/8.7.3/1.9) with SMTP id 0AA19189 for 
<HFSTG@tapr.org>; Fri, 15 Nov 1996 14:45:53 -0600 (CST) 
Received: by hil-img-6.compuserve.com (8.6.10/5.950515) 
id PAA12707; Fri, 15 Nov 1996 15:45:20 -0500 
Date: 15 Nov 96 15:43:45 EST 
From: Mike Kerry <100577.1452@CompuServe.COM> 
To: "(unknown)" <HFSIG@tapr.org> 
Subject: [HFSIG:1707] FIR filters, demodulation 
Message-ID: <961115204345_ 100577 .1452_GHW126-1@CompuServe. COM> 


Thanks Alan (N1AL) for the detailed reply. One thing however, 
you said: - 


> You need a filter both in the transmitter (to reduce adjacent-channel 
> interference) and in the receiver (to reject nearby signals). 


Does this imply there is no point in trying to use Nyquist receive 
filters when decoding sundry Amtor Pactor RTTY signals which may 
have been generated by non-Nyquist-compatible means? If so, 

then what!? 


Have you the time to elaborate on some phrases in your reply? 

The first is "a Nyquist filter is one where the signal trajectory 
passes exactly thru the proper symbol location exactly at decision 
time". What is the signal trajectory? And proper symbol location? 


Also: "for a Nyquist response the cut-off frequency should be at 1/2 
the symbol rate". 


So for 100 Bd Amtor, Fc is 50 Hz ??? I don't understand. Sorry! 


The second half of your message on windowing functions and Mathcad 
was helpful, tnx. 


If I may ask another broad question, may I elicit views on demodulation 
techniques for RTTY Amtor Pactor? e.g. FM versus AM demodulators, or 
what else? 


Thanks, 
Mike Kerry, G4BMK 


From 100577.1452@CompuServe.COM Fri Nov 15 14:45:59 1996 
Received: from hil-img-6.compuserve.com (hil-img-6.compuserve.com 
[149.174.177.136]) by tapr.org (8.7.5/8.7.3/1.9) with SMTP id 0AA19201 for 
<HFSTG@tapr.org>; Fri, 15 Nov 1996 14:45:57 -0600 (CST) 
Received: by hil-img-6.compuserve.com (8.6.10/5.950515) 
id PAA12755; Fri, 15 Nov 1996 15:45:24 -0500 
Date: 15 Nov 96 15:43:48 EST 
From: Mike Kerry <100577.1452@CompuServe.COM> 
To: "(unknown)" <HFSTG@tapr.org> 
Subject: [DSP:36] GCC56K 
Message-ID: <961115204348_ 100577 .1452_GHW126-2@CompuServe. COM> 


Tim said: 
> You can get the MS-DOS executable from 
> £tp://www.mot.com/SPS/DSP/helpline/cc/dist.wpc.cc56.tar.z 


Tim, I tried, but was told the page does not exist. 
I searched the Motorola DSP index for GCC56K but it 
found nothing. 


Mike, GA4BMK 


From alanb@polecat.sr.hp.com Fri Nov 15 15:36:53 1996 
Received: from relay.hp.com (relay.hp.com [15.255.152.2]) by tapr.org 
(8.7.5/8.7.3/1.9) with ESMTP id PAAQ2277 for <hfsig@tapr.org>; Fri, 15 Nov 1996 
15:36:48 -0600 (CST) 
Received: from srmail.sr.hp.com by relay.hp.com with ESMTP 
(1.37.109.16/15.5+ECS 3.3) id AA224013780; Fri, 15 Nov 1996 13:36:21 -0800 
Received: from polecat.sr.hp.com (algae.sr.hp.com) by srmail.sr.hp.com with ESMTP 
(1.37.109.16/15.5+ECS 3.3) id AA279373778; Fri, 15 Nov 1996 13:36:19 -0800 
Received: by polecat.sr.hp.com 
(1.37.109.16/15.5+ECS 3.3) id AAQ53593777; Fri, 15 Nov 1996 13:36:17 -0800 
From: Alan Bloom <alanb@polecat.sr.hp.com> 
Message-Id: <199611152136.AA053593777@polecat.sr.hp.com> 
Subject: SFDR 
To: hfsig@tapr.org 
Date: Fri, 15 Nov 1996 13:36:17 -0800 (PST) 


X-Mailer: ELM [version 2.4 PL21] 
Mime-Version: 1.0 

Content-Type: text/plain; charset=US-ASCII 
Content-Transfer-Encoding: 7bit 


forrerj@peak.org (Johan Forrer) wrote: 


>I assume IMD originates from 
>a non-linear process somewhere in the chain, not the quatization process; 
>that introduces wide-band noise. 


Right, the quantization is generally modeled as white noise, although it 
can depend on the input signal. For example, if the input is a sine wave 
a little more than one LSB in amplitude, then the quantized output will 
appear as a square wave, which looks like distortion, rather than noise. 
Intuitively, if the input signal is "large" and "random" in some sense, 
then the quantization error will be noise-like. 


>Am I right? If so, would that imply that if 
>we had a perfectly linear A/D convertor, and a no clipping situation, that 
>SFDR ratio would become very large? 


That's right. Many of the nonlinearities are dynamic effects that don't 
show up with low-frequency or DC signals. And of course, not only does the 
A/D converter have to be linear, but so does any other analog circuitry 
between the antenna and A/D input. 


>The bit about shaping digitization noise for later filtering is quite 
>interesting. Do you perhaps a have a reference to how that's done? 


When I get home tonight I'll check to see if the topic is covered ina 
couple DSP books I have at home. 


>I recently read a paper on a military radio that uses a one-bit A/D to 
>sample its 2.5 MHz IF - the high linearity of this A/D attributes to a quoted 
>SFDR in excess of 105 dB, which is quite usable 


One-bit delta-sigma A/D converters tend not to have very good absolute 
accuracy, but they can have very good linearity (low distortion). That's 
why they are often used in audio applications -- distortion is much more 
important than gain accuracy. The same would apply to RF applications. 
However, the analog sampling rate must be much higher than the digital 
output samples (and much higher than the RF bandwidth), which of course 
is much harder to do at RF than at audio frequencies. 


>As I understand things then, what is needed is a very flexible tunable 
>bandpass filter ahead of such a A/D. 


That would help a lot. You would then essentially have a TRF (Tuned 
Radio Frequency) receiver like they used in the 1920's, except that the 
crystal detector is replaced by a DSP! The other option is to do have a 
conventional superhet receiver front end with a relatively wide-bandwidth 
IF crystal filter and a digital DSP-based IF. The DSP could implement 


variable-bandwidth bandpass filters, most of the AGC function, noise 
blanker, notch filter, and demodulator. Compared to the all-digital 
radio, the A/D and DSP's jobs are much easier, because of the narrower 
bandwidth and reduced dynamic range requirements (assuming there is some 
analog gain control in front of the A/D.) 


By the way, the sampling rate must be > 2x the bandwidth, not 2x the 
frequency. For example, if the IF frequency is 2.5 MHz, and the bandwidth 
is 100 kHz, you can theoretically use sample rates as low as 200 kHz. 
(Although in practice it has to be somewhat higher than that.) With an 
I/Q demodulator, sample rate must be > 1x bandwidth. 


Al N1AL 


From tim@acca.nmsu.edu Fri Nov 15 20:16:43 1996 
Received: from acca.nmsu.edu (tim@acca.NMSU.Edu [128.123.3.58]) by tapr.org 
(8.7.5/8.7.3/1.9) with SMTP id UAA29230 for <hfsig@tapr.org>; Fri, 15 Nov 1996 
20:16:34 -0600 (CST) 
Received: from localhost by acca.nmsu.edu (8.6.12/acca-1.0) 
id TAA26642; Fri, 15 Nov 1996 19:16:30 -0700 
Date: Fri, 15 Nov 1996 19:16:29 -0700 (MST) 
From: Tim Baggett <tim@acca.nmsu.edu> 
X-Sender: tim@acca 
To: hfsig@tapr.org 
Subject: Re: [HFSIG:1710] [DSP:36] GCC56K 
In-Reply-To: <961115204348_100577.1452 GHW126-2@CompuServe.COM> 
Message-ID: <Pine.SUN.3.95.961115191349 .26474A-100000@acca> 
MIME-Version: 1.0 
Content-Type: TEXT/PLAIN; charset=US-ASCII 


On Fri, 15 Nov 1996, Mike Kerry wrote: 

Tim said: 

> You can get the MS-DOS executable from 

> f£tp://www.mot.com/SPS/DSP/helpline/cc/dist.wpc.cc56.tar.z 
Tim, I tried, but was told the page does not exist. 


I searched the Motorola DSP index for GCC56K but it 
found nothing. 


VV VV VV V VV 


How in the world did this get over to the HFSIG list??!! I thought it was 
on the DSP list were I get it at work! 


Anyhow, leave the filename off. I guess netscrape doesn't like a URL that 
goes for the specific file. Chop it off after the /cc and you will get the 


directory. 


BTW, the manual gcc56kman.zip or something like that is in a stupid 


FrameMaker format. I have one of the docs guys converting it over to PDF 
format. They tend to think everyone in the world has Frame Maker. I never 
heard of it until I started work there. 


73 
Tim 


From alanb@polecat.sr.hp.com Fri Nov 15 20:19:22 1996 
Received: from hp.com (hp.com [15.255.152.4]) by tapr.org (8.7.5/8.7.3/1.9) with 
ESMTP id UAA29656 for <hfsig@tapr.org>; Fri, 15 Nov 1996 20:19:18 -0Q600 (CST) 
Received: from srmail.sr.hp.com by hp.com with ESMTP 
(1.37.109.16/15.5+ECS 3.3) id AAQ82750756; Fri, 15 Nov 1996 18:19:16 -0800 
Received: from polecat.sr.hp.com (algae.sr.hp.com) by srmail.sr.hp.com with ESMTP 
(1.37.109.16/15.5+ECS 3.3) id AAQ26900755; Fri, 15 Nov 1996 18:19:15 -0800 
Received: by polecat.sr.hp.com 
(1.37.109.16/15.5+ECS 3.3) id AA208680754; Fri, 15 Nov 1996 18:19:14 -0800 
From: Alan Bloom <alanb@polecat.sr.hp.com> 
Message-Id: <199611160219.AA208680754@polecat.sr.hp.com> 
Subject: More on filters 
To: hfsig@tapr.org 
Date: Fri, 15 Nov 1996 18:19:14 -0800 (PST) 
X-Mailer: ELM [version 2.4 PL21] 
Mime-Version: 1.0 
Content-Type: text/plain; charset=US-ASCII 
Content-Transfer-Encoding: 7bit 


Mike Kerry <100577.1452@compuserve.com> wrote: 


>you said: - 

> 

>> You need a filter both in the transmitter (to reduce adjacent-channel 
>> interference) and in the receiver (to reject nearby signals). 

> 

>Does this imply there is no point in trying to use Nyquist receive 
>filters when decoding sundry Amtor Pactor RTTY signals which may 

>have been generated by non-Nyquist-compatible means? If so, 

>then what!? 


Ideally, the filters in the receiver and transmitter should be matched 
so that the net response is Nyquist. You can always find a receive 
filter that accomplishes that by adding an equalizing filter whose 
response is the reciprocal of transmit filter response. (Theoretically, 
anyway.) But of course you have to know the transfer function of the 
transmit filter. 


Fortunately the filters don't have to be perfect. People got along 
fine with analog filters (inherently non-Nyquist) for years. Of course, 
they had to make do with wider bandwidths than necessary to keep the 
inter-symbol interference within reason. 


>Have you the time to elaborate on some phrases in your reply? 


>The first is "a Nyquist filter is one where the signal trajectory 
>passes exactly thru the proper symbol location exactly at decision 
>time". What is the signal trajectory? And proper symbol location? 


By "signal trajectory" I just mean a plot of signal versus time. At 
the receiver detector (after filtering), the instantaneous value of the 
signal is measured at the decision time, once per symbol. The possible 
symbol locations depend on the modulation type. For FSK or BPSK, there 
are only two possibilities. For 256 QAM, there are 16 possible symbol 
locations for the I channel and 16 for the Q channel, giving a total of 
16*16 = 256 possible symbol locations on the I/Q plane. 


The job of the detector is to read the signal value at the decision 
time and decide which of the possible symbol locations the signal is 
closest to. For FSK, if the symbol locations are +1 and -1, then any 
Signal value above 0 is considered a +1 and anything below is a -1. 


>Also: "for a Nyquist response the cut-off frequency should be at 1/2 
>the symbol rate". 

> 

>So for 100 Bd Amtor, Fc is 50 Hz ??? I don't understand. Sorry! 


Yes. Theoretically, a signal doesn't need to have any energy above 

1/2 the symbol rate. Consider a 1-bit-per-symbol modulation like FSK. 
The fastest you can make that signal change is to send it a continuous 
series of alternating one's and zero's. So if the baud rate is 100 
symbols/sec, the unfiltered signal would be a 50 Hz square wave. 

* (See disclaimer below) If you filtered it with a brick-wall filter 
with a cutoff at 50 Hz (i.e. a Nyquist filter with an alpha = 0), the 
square wave would be turned into a sine wave, and no information would 
be lost. Any other combination of 1's and O's can only have even lower 
frequency components. For example 110011001100... has a repetition rate 
of Fs/4. 


Of course, a practical filter can't have a brick-wall frequency 
response. But to be Nyquist (no inter-symbol interference), it must 
be half-scale (-6 dB) at 1/2 the symbol rate and be anti-symmetrical 
about that point on the frequency axis. A raised-cosine filter is one 
that fits that description. 


>If I may ask another broad question, may I elicit views on demodulation 
>techniques for RTTY Amtor Pactor? e.g. FM versus AM demodulators, or 
>what else? 


AM demodulators are supposed to work better than FM discriminators. 
Years ago, I used a Frederick Electronics demodulator quite a bit on 
the HF bands. It could be switched between FM and AM modes. I could 
never see much difference, as a practical matter. As I recall, that 
demod had circuitry to dynamically adjust the decision level of the 
"slicer" (mark/space comparator), to account for selective fading 

(one tone stronger than the other) and interference affecting one 
frequency more than the other. The box did indeed seem to work better 
than standard designs. 


Al N1AL 


From beppe@ns1.dinamica.it Sat Nov 16 04:30:43 1996 

Received: from nsi.dinamica.it (root@ns1.dinamica.it [194.28.13.2]) by tapr.org 
(8.7.5/8.7.3/1.9) with SMTP id EAAQ6640 for <hfsig@tapr.org>; Sat, 16 Nov 1996 
04:30:32 -0600 (CST) 

From: beppe@ns1.dinamica.it 

Received: from ilaria (ilaria.dinamica.it [194.28.13.150]) by ns1.dinamica.it 
(8.6.11/8.6.9) with SMTP id MAAQ4907 for <hfsig@tapr.org>; Sat, 16 Nov 1996 
12:03:27 +0100 

Date: Sat, 16 Nov 1996 12:03:27 +0100 

Message-Id: <1.5.4.16.19961116113718 .096fa3ea@pt.dinamica.it> 

X-Sender: beppe@pt.dinamica.it 

X-Mailer: Windows Eudora Light Version 1.5.4 (16) 

Mime-Version: 1.0 

Content-Type: text/plain; charset="us-ascii" 

X-Priority: 1 (Highest) 

To: hfsig@tapr.org 

Subject: unsubscribe 


From forrerj@peak.org Sat Nov 16 21:48:31 1996 

Received: from PEAK.ORG (root@PEAK.ORG [198.68.22.17]) by tapr.org 
(8.7.5/8.7.3/1.9) with SMTP id VAA27051 for <hfsig@tapr.org>; Sat, 16 Nov 1996 
21:48:28 -0600 (CST) 

Received: from p08.tO0.monrotel.com (p08.tO.monrotel.com [198.68.25.41]) by 
PEAK.ORG (8.6.13/8.6.7) with SMTP id TAAQ2151 for <hfsig@tapr.org>; Sat, 16 Nov 
1996 19:48:32 -0800 

Message-Id: <199611170348.TAAQ2151@PEAK.ORG> 

X-Sender: forrerj@peak.org 

X-Mailer: Windows Eudora Version 1.4.4 

Mime-Version: 1.0 

Content-Type: text/plain; charset="us-ascii" 

Date: Sat, 16 Nov 1996 19:51:57 -0800 

To: hfsig@tapr.org 

From: forrerj@peak.org (Johan Forrer) 

Subject: Re: [HFSIG:1709] FIR filters, demodulation 


Mike, 
My 2 cents on the subject; 


> 

>If I may ask another broad question, may I elicit views on demodulation 
>techniques for RTTY Amtor Pactor? e.g. FM versus AM demodulators, or 
>what else? 

> 

>Thanks, 

> 


>Mike Kerry, G4BMK 
> 
> 


My experience has been that a MAP receiver exhibits exceptional robustness 
for HF operation. Such a MAximum Postiori receiver may be considered a 
filter bank and a selector switch that selects the filter output with 
largest magnitude. There are some elegant mathematics to support this, which 
can be extended to produce matched filter theory. 


Good adjacent channel interference is of prime importance. 


With synchronous data systems, such as AMTOR and Pactor, the demodulator and 
detector operation can be controlled as a byproduct from the data decoding 
process. In this case a software PLL can guide the demodulator/detector to 
clean up data decisions. The performance is not as good as a real coherent 
demodulator, but can approach that. 


A novel idea is to make use of soft-decision decoding, i.e., Viterbi 
decoding to aid in bit synchronisation and data extraction. An example where 
this have been done successfully is shown in the work of Dave Mills, W3HCF 
where he uses such a scheme to decode RTTY and FEC AMTOR. This by itself is 
worth a couple of dB and also buys further robustness. 


Yes, it is possible to decode FSK using phase information, i.e., multiply 
the signal by a delayed version of itself. The FSK demodulators that Pawel, 
SP9VRC wrote for the EVM does this, so does the DSP93 modems of Frank 
Perkins. It works reasonably well, howeber, I am of the opinion that this 
technique does not show the same robustness as the filter-type approach 
described above. Possibly it is a tradeoff between phase stability/ambiuity 
against spectral power measurement. I suspect the latter being a more 
statistically robust measure. 


Hope this helps. 
--Johan, KC7WW 


From 100577.1452@CompuServe.COM Sun Nov 17 17:57:17 1996 
Received: from dub-img-3.compuserve.com (dub-img-3.compuserve.com 
[149.174.206.133]) by tapr.org (8.7.5/8.7.3/1.9) with SMTP id RAA29968 for 
<HFSTG@tapr.org>; Sun, 17 Nov 1996 17:57:16 -0600 (CST) 
Received: by dub-img-3.compuserve.com (8.6.10/5.950515) 
id SAA21458; Sun, 17 Nov 1996 18:56:41 -0500 
Date: 17 Nov 96 18:55:06 EST 
From: Mike Kerry <100577.1452@CompuServe.COM> 
To: "(unknown)" <HFSIG@tapr.org> 
Subject: [HFSIG:1713] Filters and Demods 
Message-ID: <961117235505_100577.1452_ GHW48-1@CompuServe. COM> 


Thanks to Alan and Johan for their contributions. 


I have been experimenting with an FM demodulator, and 


also a matched filter approach, taking the difference 

in magnitude between mark and space filters (not sure if 
that constitutes an AM decoder or what. Someone is bound 
to enlighten me). 


The FM system is currently giving better results on higher 
baud rates (e.g. 200 Bd Pactor) and the matched filter 
approach is better on RTTY. (These both being compared to a 
BARTG Multyterm matched filter op-amp terminal unit). 


I like the idea of running multiple filters in parallel 

and choosing the set that gives maximum eye-height or 
difference - or of adjusting filter coefficients on the fly 

to maximise. With modes like Pactor and AX25 especially, 

with frame checking being done in the DSP too, one can run 
multiple techniques in parallel and just see which gives you a 
valid CRC for the frame. This would be nice for monitoring 
Pactor, as you can effectively be continuously running 
optimally at both 100 and 200 Bd. 


With non self-checking modes like RTTY, is there a danger of 
other factors like QRM affecting eye-height and confusing 
the filter choice, or is eye-height or matched filter 
difference always going to be a good guide? 


Can someone tell me please how to compute the optimum receive 
filter pass-band width for a given Baud rate and Shift, to 
maximise legitimate energy capture. And are you talking about 
3 dB or 6 dB points. 


Some background information: 

My DSP platform at present is a 20 MIPS TMS320C51 processor 

with TLC32044 AIC, 64K full speed SRAM and 64K Flash. I have the 
TI Coff Assembler, and 'C' Compiler (rather bugged!). Main uses 
to date have been for 1200 Baud FSK and 2400 Baud QPSK used 

over trunked radio networks. Now looking at the HF modes. 

I am awaiting delivery of my DSP56002EVM. 


73% 


Mike Kerry, G4BMK 


From k5cnf£1@juno.com Sun Nov 17 20:30:48 1996 
Received: from x9.boston.juno.com (x9.boston.juno.com [205.231.100.25]) by 
tapr.org (8.7.5/8.7.3/1.9) with ESMTP id UAAQ9095 for <HFSIG@TAPR.ORG>; Sun, 17 
Nov 1996 20:30:46 -Q600 (CST) 
Received: (from k5cnf1@juno.com) by x9.boston.juno.com (queuemail) 
id VAA23542; Sun, 17 Nov 1996 21:30:15 EST 
To: HFSIG@tapr.org 
Date: Sun, 17 Nov 1996 08:15:44 PST 
Subject: TU-170 
Message-ID: <19961117 .082836.8279.0.k5cnf£1@juno.com> 


X-Mailer: Juno 1.00 
X-Juno-Line-Breaks: 3-5 
From: k5cnf1@juno.com (Richard B Morrow) 


anyone out there have any idea as to how I could put an ancient Flesher 
TU-170 to use with my newer computers. The only program I have is for 
the ancient Radio Shack Model 1 which is not an option to use. I have 
the docs on the tu, which helps. 


Richard, K5CNF 


From 100577.1452@CompuServe.COM Mon Nov 18 04:52:25 1996 
Received: from arl-img-2.compuserve.com (arl-img-2.compuserve.com 
[149.174.217.132]) by tapr.org (8.7.5/8.7.3/1.9) with SMTP id EAAQ7459 for 
<HFSTG@tapr.org>; Mon, 18 Nov 1996 04:52:23 -0600 (CST) 
Received: by arl-img-2.compuserve.com (8.6.10/5.950515) 
id FAA24198; Mon, 18 Nov 1996 05:51:53 -0500 
Date: 18 Nov 96 05:50:39 EST 
From: Mike Kerry <100577.1452@CompuServe.COM> 
To: "(unknown)" <HFSIG@tapr.org> 
Subject: [HFSIG:1717] TU-170 
Message-ID: <961118105038_100577.1452 GHW47-1@CompuServe. COM> 


Richard, K5CNF wrote: 


>anyone out there have any idea as to how I could put an ancient Flesher 
>TU-170 to use with my newer computers. The only program I have is for 
>the ancient Radio Shack Model 1 which is not an option to use. I have 
>the docs on the tu, which helps. 


Richard, try contacting Steve, AC4IW, at Spheretron. He can supply 
the BMK-Multy software which does RTTY, Amtor and Pactor etc. on a PC 
and I'm pretty sure the TU-170 is amongst TU's that have been interfaced. 


Spheretron 25 Eastwood Road, P.0.Box 5964, Asheville NC 28813 
Tel: (704) 274 4646 


Mike, GA4BMK 


From w5zit@juno.com Mon Nov 18 10:03:44 1996 
Received: from x3.boston.juno.com (x3.boston.juno.com [205.231.100.22]) by 
tapr.org (8.7.5/8.7.3/1.9) with ESMTP id KAA18228 for <hfsig@tapr.org>; Mon, 18 
Nov 1996 10:03:37 -Q600 (CST) 
Received: (from w5zit@juno.com) by x3.boston.juno.com (queuemail) 
id LAB28179; Mon, 18 Nov 1996 11:03:01 EST 
To: hfsig@tapr.org 
Subject: Re: [HFSIG:1717] TU-170 
Message-ID: <19961118.110303.7879.1.w5zit@juno. com> 
References: <19961117 .082836.8279.0.k5cn£1@juno. com> 
X-Mailer: Juno 1.15 


X-Juno-Line-Breaks: 2-3,7-8,13-14,19-20,24-25,27-28, 30-32 
From: w5zit@juno.com (James H Brown) 
Date: Mon, 18 Nov 1996 11:03:01 EST 


Richard - the TU-170 was designed for 45 Baud RTTY - but has the makings 
of a front end for the faster Baud rates if you do a little tinkering 
with it. 


Take a look at the filtering after the mark/space detector and see if the 
output transitions are restricted to a slower rate. You may have to 
decrease the value of one or more filter caps to get the higher data 
rates. 


There are several packages that run RTTY from a PC that would require no 
mod to the TU-170 at all - except for perhaps an adapter to get the 
RS-232 levels conditions for your PC. I don't recall if the I/O of the 
TU-170 is RS-232 compatable or just TTL - but you probably have all the 
specs there in your docs. 


I have used an Amtor freebie program on HF with some success, and the 
TU-170 should work well on Amtor with the Baud filter modified to pass 
the 100 Baud data. On the other hand - if the Flesher specs say it was 
designed to pass 100 Baud RTTY signals - then no modification would be 
required for Amtor. 


There is a program that can be purchased to run Pactor to an external 
modem also - which would require modifying the TU-170 Baud fliter to pass 
the 200 Baud Pactor signals. I do not recall the name of the program - 
but I have worked several hams using it. 


Look on the QRZ CD Rom for programs that run on the PC to run various 
modes. You may have some ham buddies who have that CD who can help. 


If you have trouble locating any of the specific programs - let me know 
and I will see what I can dig up. 


73 - Jim - w5zit@juno.com 


From alanb@polecat.sr.hp.com Mon Nov 18 16:58:09 1996 
Received: from paloalto.access.hp.com (daemon@paloalto.access.hp.com 
[15.254.56.2]) by tapr.org (8.7.5/8.7.3/1.9) with ESMTP id QAA07983 for 
<hfsig@tapr.org>; Mon, 18 Nov 1996 16:56:56 -0600 (CST) 
Received: from srmail.sr.hp.com by paloalto.access.hp.com with ESMTP 
(1.37.109.16/15.5+ECS 3.3) id AA190247806; Mon, 18 Nov 1996 14:56:47 -0800 
Received: from polecat.sr.hp.com (algae.sr.hp.com) by srmail.sr.hp.com with ESMTP 
(1.37.109.16/15.5+ECS 3.3) id AA128817805; Mon, 18 Nov 1996 14:56:46 -0800 
Received: by polecat.sr.hp.com 
(1.37.109.16/15.5+ECS 3.3) id AAQ67387805; Mon, 18 Nov 1996 14:56:45 -0800 
From: Alan Bloom <alanb@polecat.sr.hp.com> 
Message-Id: <199611182256.AA067387805@polecat.sr.hp.com> 
Subject: Sigma Delta 
To: hfsig@tapr.org 
Date: Mon, 18 Nov 1996 14:56:44 -0800 (PST) 


X-Mailer: ELM [version 2.4 PL21] 
Mime-Version: 1.0 

Content-Type: text/plain; charset=US-ASCII 
Content-Transfer-Encoding: 7bit 


I promised to try to find a reference explaining Sigma-Delta A/D converters. 
None of my DSP textbooks seem to cover the topic. I did find an app note 
from Harris Semiconductor (AN9504, May 1995) that does a pretty good job. 

I can copy it if anyone is interested. 


Basically a sigma-delta converter is formed thus: 


Taput <<=- >|+ | | | | Comparator | 
| Summer |-->| Integrator |-->| (41-bit A/D) |--*-> Digital 
aie Reema ter | Vaca Sorin Sed topes | Ws Sea | | Output 


| 
| | | 
wen nnn nnennee- | 1-bit DAC |<-----------------------! 


The digital output is a 1-bit signal at a high bit rate. It then goes to 
a low-pass filter and decimator to produce an N-bit output at a lower rate. 


Let's say the 1-bit DAC puts out +1V for a "1" and -1V for a "O". 
(Actually you'd probably just use a CMOS gate that puts out +5V and OV, 
if you don't mind having a unipolar analog input.) If the analog input 
is OV, then the feedback loop forces the digital output to be half 1's 
and half 0's so that the integrator input sees half +1V and half -1V. 
The output of the integrator is then a small triangle wave centered 
about zero volts. If the analog input is +0.8V (90% full scale), then 
the digital output is 90% 1's and 10% O's. 


Because there is an integrator (-6 dB per octave frequency response) in 
the feedback path, the quantization noise at the digital output has a 
+6 dB/octave rising characteristic, dropping to minus infinity (zero 
error) at DC. 


If you are using a large oversample ratio (high sampling rate), then 
the digital filter in the decimator can filter off most of that high- 
frequency quantization noise. Even though a 1-bit A/D theoretically 
only has 6 + 1.76 = 7.76 dB S/N ratio, after filtering it can be 
equivalent to, for example, a 16-bit A/D. The digital filter has a 
1-bit input and an N-bit output. 


By using a second-order converter with two integrators, you get a 
12 dB/octave frequency response. Third-order gives 18 dB/octave, etc. 


The advantage of the sigma-delta A/D is that the linearity is not 

affected by nonlinearities in the internal ciruitry of a conventional 
multi-bit A/D. Also, most of the circuitry is digital, rather than analog, 
which makes it easier to design the whole thing into a monolithic IC. 


Alan Bloom N1AL 


From k5cnf£1@juno.com Mon Nov 18 19:20:38 1996 
Received: from x9.boston.juno.com (x9.boston.juno.com [205.231.100.25]) by 
tapr.org (8.7.5/8.7.3/1.9) with ESMTP id TAA15375 for <hfsig@tapr.org>; Mon, 18 
Nov 1996 19:20:34 -0600 (CST) 
Received: (from k5cnf1@juno.com) by x9.boston.juno.com (queuemail) 
id UAB18380; Mon, 18 Nov 1996 20:13:20 EST 
To: hfsig@tapr.org 
Date: Mon, 18 Nov 1996 06:38:42 PST 
Subject: Re: [HFSIG:1718] TU-170 
Message-ID: <19961118.065406.8279.1.k5cnf£1@juno.com> 
References: <961118105038_100577.1452 GHW47-1@compuserve. com> 
X-Mailer: Juno 1.00 
X-Juno-Line-Breaks: 1-5 
From: k5cnf1@juno.com (Richard B Morrow) 


OK MIKE Ha! had the caps lock on, you are the second person to recommend 
that program. . 


Thanks a lot. 
Richard, K5CNF 


From k5cnf£1@juno.com Mon Nov 18 19:31:19 1996 
Received: from x9.boston.juno.com (x9.boston.juno.com [205.231.100.25]) by 
tapr.org (8.7.5/8.7.3/1.9) with ESMTP id TAA15872 for <hfsig@tapr.org>; Mon, 18 
Nov 1996 19:31:16 -0600 (CST) 
Received: (from k5cnf1@juno.com) by x9.boston.juno.com (queuemail) 

id UAC18380; Mon, 18 Nov 1996 20:13:20 EST 
To: hfsig@tapr.org 


Date: Mon, 18 Nov 1996 06:43:56 PST 

Subject: Re: TU-170 

Message-ID: <19961118.065406.8279.2.k5cnf£1@juno.com> 
References: <19961118.110303.7879.1.w5zit@juno.com> 
X-Mailer: Juno 1.00 

X-Juno-Line-Breaks: 2-6 

From: k5cnf1@juno.com (Richard B Morrow) 


Ok, Jim, I know some one who has that CD.ROM. I have the capabilities of 
being able to look at the signals in the TU, several scopes,so I will 
check that stuff out 


Thanks loads 
Richard, K5CNF 


From karn@qualcomm.com Mon Nov 18 20:47:58 1996 

Received: from servo.qualcomm.com (servo.qualcomm.com [129.46.101.170]) by 
tapr.org (8.7.5/8.7.3/1.9) with ESMTP id UAA19634 for <hfsig@tapr.org>; Mon, 18 
Nov 1996 20:47:56 -0600 (CST) 

Received: (from karn@localhost) by servo.qualcomm.com (8.8.3/1.4/8.7.2/1.9) id 


SAA09847; Mon, 18 Nov 1996 18:47:23 -0800 (PST) 

Date: Mon, 18 Nov 1996 18:47:23 -0800 (PST) 

From: Phil Karn <karn@qualcomm. com> 

Message-Id: <199611190247 .SAA09847@servo.qualcomm. com> 


To: hfsig@tapr.org 
In-reply-to: <199611170348.TAAQ2151@PEAK.ORG> (forrerj@peak.org) 
Subject: Re: [HFSIG:1715] Re: FIR filters, demodulation 


I would like to add to Johan's and Alan's excellent comments by giving 
a little fundamental theory, as it's essential in understanding their 
remarks. Otherwise, all that complexity about Nyquist and raised 
cosine responses seems baffling. 


Two requirements must be satisfied simultaneously to maximize the 
performance of a digital link. 


First, the receiver filter must be "matched" to the transmitted signal 
spectrum. That is, the receiver filter amplitude response must match 
the amplitude of the transmitted signal spectrum. Additionally, if 
there is group delay distortion (frequency-dependent delay) in the 
transmitted signal, as can happen with sloppy analog filter design in 
the modulator, then the matched filter should have the inverse delay 
curve to compensate for the transmitter filter. 


Second, the combination of the transmitter filter and the receiver 
filter should have a Nyquist response, i.e., the group delay is flat 
and the frequency response is anti-symmetrical around the frequency 
corresponding to one-half the data rate. 


The first requirement maximizes the SNR performance against noise and 
interference while the second requirement minimizes self-interference, 
i.e., intersymbol interference, at the important moment in the center 
of each bit when you sample it. Note that the ISI is *not* zero on 
either side of the correct sampling instant, which is why it's 
important to have accurate clock recovery. In an eye diagram, this ISI 
shows up as "jitter" in the eye on either side of the center. 


The "square-root-of-raised-cosine" approach comes about as follows: 


A raised cosine channel response satisfies requirement #2 

above. Though it is not the only response to do so (anything with the 
proper symmetry around 1/2 the data rate will do), it is the easiest 
to implement and to model. In particular, a brick-wall filter that 
cuts off precisely at 1/2 of the data rate will also do, but 
brick-wall filters are notoriously impossible to realize in practice. 


Second, if you take the square root of the raised cosine response and 
implement it in both the transmitter and the receiver, then the 
receiver's response will be matched to the transmitter's spectrum, 
meeting requirement #1 above. Furthermore, the combination of the two 
square-root responses, when multiplied together, gives the original 
raised-cosine response, which continues to meet requirement #2. 


This assumes that data bits are sent into the transmitter filter as 
impulses of infinite amplitude and infintesmal duration. As such 
impulses have a uniformly flat frequency spectrum, the spectrum of the 
resulting signal will be that of a square root of raised cosine -- to 
which the receiver filter is matched, because it also has a square 
root of raised cosine response. 


In a real transmitter that uses DSP, these impulses can be closely 
approximated by single-sample impulses. E.g., if the sampling rate is 
8x the bit rate (a common choice) then the data stream fed into the 
transmitter filter might look like this: 


-10000000+710000000-1... 
where the data is bipolar (1 remains 1 and © becomes -1). 


As an alternative (often done in hardware) the data signal is held for 
the duration of each bit, e.g., 


-1 -1 -1 -2 -2 -2 -2 -1 +2 41 «+72«424«42«4+2«41 42 ~«-1~««w#«.. 


In this case, the spectrum of the signal is xnot*« flat -- it has a sin(x)/x 
shape, so you need a x/sin(x) correction factor in the transmitter filter. 
The filter design programs often give this to you as an option, e.g., 

as a x/sin(x) * sqrt(raised cosine) response. My own preference so far 

for DSP filters is to use the data impulse approach so the transmitter 

and receiver filters can be identical. 


Now all this assumes you have control over both the receiver and 
transmitter. But if you're designing a receiver for an arbitrary RTTY 
transmitter, you're going to have to be more flexible. The transmitter 
might not have been designed to have a square-root-of-raised-cosine 
response. This means you'll generally have to use a suboptimum filter 
(from a matched filter standpoint) at the receiver in order to 
eliminate ISI on the desired signal, or vice versa. The demod xwillx 
work, but you'd have worse SNR performance than you'd like. 


Alternatively, you could figure out what the transmitter filter looks 
like, then make a matched filter at the receiver. This would leave 
ISI, which you could take out with a Viterbi decoder (assuming the 
duration of the ISI is not too great, which would otherwise entail a 
Viterbi decoder with an impractical number of states). 


Still another possibility is to build an equalizer to deal with the 
nonideal transmitter filter, but this gets quite hairy and advanced. 


This is why I personally find it more interesting to design new links 
from scratch where I can control both ends of the link. Not only can I 
make the frequency responses optimum, but I can add FEC and control 
other aspects of the link protocol. 


Phil 


From ronald_evans@pipeline.com Mon Nov 18 23:35:09 1996 

Received: from itchy.mindspring.com (itchy.mindspring.com [204.180.128.6]) by 
tapr.org (8.7.5/8.7.3/1.9) with ESMTP id XAA00127 for <hfsig@tapr.org>; Mon, 18 
Nov 1996 23:35:07 -Q600 (CST) 

Received: from hal (user-37kb947.dialup.mindspring.com [207.69.164.135]) by 
itchy.mindspring.com (8.7.5/8.7.3) with SMTP id AAA27232 for <hfsig@tapr.org>; 
Tue, 19 Nov 1996 00:35:05 -0500 (EST) 

Message-Id: <2.2.32.19961119053503 .007033b0@pop.pipeline.com> 

X-Sender: ronald_evans@pop.pipeline.com 

X-Mailer: Windows Eudora Pro Version 2.2 (32) 

Mime-Version: 1.0 

Content-Type: text/plain; charset="us-ascii" 

Date: Tue, 19 Nov 1996 00:35:03 -0500 

To: hfsig@tapr.org 

From: "Ronald H. Evans" <ronald_evans@pipeline.com> 

Subject: Clover and the P-38 


Is this the place to discuss Clover, Pactor II, software to use with my P-38 
and related topics? I am especially interested in battery powered portable 
operation of these modes. Tnx, Ron, K4KTB 


From dts@dtsdata.intnet.bj] Tue Nov 19 01:01:10 1996 
Received: from newserver.dtsdata.intnet.bj (dtsdata.intnet.bj [194.51.163.246]) by 
tapr.org (8.7.5/8.7.3/1.9) with SMTP id BAA11367 for <hfsig@tapr.org>; Tue, 19 Nov 
1996 01:00:59 -0600 (CST) 
Received: from [192.168.0.92] by newserver.dtsdata.intnet.bj (NTMail 3.01.03) id 
xa004235; Tue, 19 Nov 1996 07:01:16 +0200 
Received: by newserver.dtsdata with Microsoft Mail 
id <Q1BBD5EF .C0226440@newserver.dtsdata>; Tue, 19 Nov 1996 08:00:38 +-100 
Message-ID: <Q1BBD5EF .CO226440@newserver.dtsdata> 
From: Peter Schulze <dts@dtsdata.intnet.bj> 
To: "'hfsig@tapr.org'" <hfsig@tapr.org> 
Subject: RE: [HFSIG:1724] Clover and the P-38 
Date: Tue, 19 Nov 1996 08:00:32 +-100 
Encoding: 10 TEXT 
X-Info: EURAF/DTS Mail Server Cotonou 


The IDRA reflector discussed these issues, check 

http: //dtsdata. intnet.bj/idra/newsub.htm 

for details. Previous articles on that subject are archived at: 
http: //dtsdata.intnet.bj/idralog/subject.htm 


73 
Peter TY1PS 


From alanb@polecat.sr.hp.com Tue Nov 19 15:41:15 1996 

Received: from palrel1.hp.com (palrel1.hp.com [15.253.72.10]) by tapr.org 
(8.7.5/8.7.3/1.9) with ESMTP id PAA24433 for <hfsig@tapr.org>; Tue, 19 Nov 1996 
15:41:13 -0600 (CST) 


Received: from srmail.sr.hp.com (srmail.sr.hp.com [15.4.45.14]) by palrel1.hp.com 
with ESMTP (8.7.5/8.7.3) id NAAQ1327 for <hfsig@tapr.org>; Tue, 19 Nov 1996 
13:41:11 -0800 (PST) 
Received: from polecat.sr.hp.com (algae.sr.hp.com) by srmail.sr.hp.com with ESMTP 
(1.37.109.16/15.5+ECS 3.3) id AA227429670; Tue, 19 Nov 1996 13:41:11 -0800 
Received: by polecat.sr.hp.com 
(1.37.109.16/15.5+ECS 3.3) id AAQ95919670; Tue, 19 Nov 1996 13:41:10 -0800 
From: Alan Bloom <alanb@polecat.sr.hp.com> 
Message-Id: <199611192141.AA095919670@polecat.sr.hp.com> 
Subject: RTTY 
To: hfsig@tapr.org 
Date: Tue, 19 Nov 1996 13:41:10 -0800 (PST) 
X-Mailer: ELM [version 2.4 PL21] 
Mime-Version: 1.0 
Content-Type: text/plain; charset=US-ASCII 
Content-Transfer-Encoding: 7bit 


Phil Karn <karn@qualcomm.com> wrote: 


> As an alternative (often done in hardware) the data signal is held for 
>the duration of each bit, e.g., 


> 
>-1 -2 -1 -2 -21 -12 -2 -1 42 421 «4+72«42«42 «42 «41 42 ~-1~«... 

> 

>In this case, the spectrum of the signal is xnot*« flat -- it has a sin(x)/x 


>shape, so you need a x/sin(x) correction factor in the transmitter filter. 


>Now all this assumes you have control over both the receiver and 
>transmitter. But if you're designing a receiver for an arbitrary RTTY 
>transmitter, you're going to have to be more flexible. The transmitter 
>might not have been designed to have a square-root-of-raised-cosine 
>response. This means you'll generally have to use a suboptimum filter 
>(from a matched filter standpoint) at the receiver in order to 
>eliminate ISI on the desired signal, or vice versa. The demod xwillx 
>work, but you'd have worse SNR performance than you'd like. 


>Still another possibility is to build an equalizer to deal with the 
>nonideal transmitter filter, but this gets quite hairy and advanced. 


Most traditional RTTY transmitters get around the ISI problem simply by 
using a filter cutoff frequency much higher than needed. This results 
in a wider transmitted bandwidth, but at 45 or 100 baud, who cares? 
Most receivers don't have a narrow enough crystal filter to make use of 
signals separated by 100 Hz anyway (and would have horrible group delay 
variation if they did.) 


In designing the receiver, you wouldn't go far wrong to assume that 
there is no transmit filter and that each mark or space tone is held 

for the entire duration of the symbol as Phil illustrated above. The 
receiver filter can include the sin(x)/x correction and a Nyquist filter 
convolved together into one set of filter coefficients to get a net 
almost-Nyquist response. 


To generate the FIR filter coefficients, the easiest way would be to 
multiply the raised-cosine frequency response with PI*x/sin(PI*x) and 
do an inverse FFT on the result to get the impulse response, which is 
the FIR filter coeficients. Then apply your favorite window function 
to truncate to the length of your filter. 


Another refinement would be to cancel out the amplitude and group delay 
variation in the receiver crystal filter. You would like to use as 
narrow a filter as possible to eliminate interference, but narrow 
analog filters add ISI. To measure the filter response you could 
generate a narrow RF pulse (use the Woodpecker as a test signal? :=) 
and use the demodulator's A/D to measure the impulse response. The 
reciprocal of that would then be convolved with the receiver filter 
coefficients as determined above. When is some manufacturer going to 
design a demod with this feature built in? 


Alan Bloom N1AL 


From karn@qualcomm.com Tue Nov 19 23:10:13 1996 

Received: from servo.qualcomm.com (servo.qualcomm.com [129.46.101.170]) by 
tapr.org (8.7.5/8.7.3/1.9) with ESMTP id XAA20657 for <hfsig@tapr.org>; Tue, 19 
Nov 1996 23:10:11 -0600 (CST) 

Received: (from karn@localhost) by servo.qualcomm.com (8.8.3/1.4/8.7.2/1.9) id 
VAAO2017; Tue, 19 Nov 1996 21:09:39 -Q800 (PST) 

Date: Tue, 19 Nov 1996 21:09:39 -@800 (PST) 

From: Phil Karn <karn@qualcomm. com> 

Message-Id: <199611200509.VAAQ2017@servo.qualcomm. com> 

To: hfsig@tapr.org 

In-reply-to: <199611152136.AAQ53593777@polecat.sr.hp.com> (message from Alan Bloom 
on Fri, 15 Nov 1996 15:43:42 -0600 (CST)) 

Subject: Re: [HFSIG:1711] SFDR 


>By the way, the sampling rate must be > 2x the bandwidth, not 2x the 
>frequency. For example, if the IF frequency is 2.5 MHz, and the bandwidth 


One comment here -- although the A/D converter can take its time when 
the IF bandwidth is much less than the frequency, the sample-and-hold 
used ahead of the A/D converter must still have a very short sample 
time compared to the period of the RF waveform. As I understand it, 
the sample-and-hold circuits are one of the limiting factors on the 
performance of a digital radio that uses direct IF sampling. 


Phil 


From s5éa@s55tcp.ampr.org Wed Nov 20 03:00:39 1996 

Received: from s55tcp.ampr.org (ljutcp.hamradio.si [193.2.132.80]) by tapr.org 
(8.7.5/8.7.3/1.9) with SMTP id DAAQ9005 for <hfsig@tapr.org>; Wed, 20 Nov 1996 
03:00:32 -0600 (CST) 

Date: Wed, 20 Nov 96 08:56:31 EST 

Message-Id: <14942@s55tcp.ampr.org> 

From: Marijan Miletic <s56a@s55tcp.ampr.org> 

Reply-To: S56A@s55tcp.ampr. org 

To: hfsig@tapr.org 


Subject: KISS explanations 


Alan's, N1AL explanation of sigma-delta explanation reminded me of even simler 
circuit diagram using comparator, D-type flip-flop and RC feedback in some old 
Motorola book on telecommunicattion IC's. Many DSP topics are explained in 
straightforward fashion in TI application books while the others involve a lot 
of math to fill the pages. However, when the going gets tough, one has to 
revert to abstract math :-) 

73 de Mario, S56A, N1YU. 


From alanb@polecat.sr.hp.com Wed Nov 20 12:38:31 1996 
Received: from palrel1.hp.com (palrel1.hp.com [15.253.72.10]) by tapr.org 
(8.7.5/8.7.3/1.9) with ESMTP id MAAQ2356 for <hfsig@tapr.org>; Wed, 20 Nov 1996 
12:38:28 -0600 (CST) 
Received: from srmail.sr.hp.com (srmail.sr.hp.com [15.4.45.14]) by palrel1.hp.com 
with ESMTP (8.7.5/8.7.3) id KAA16575 for <hfsig@tapr.org>; Wed, 20 Nov 1996 
10:38:22 -0800 (PST) 
Received: from polecat.sr.hp.com (algae.sr.hp.com) by srmail.sr.hp.com with ESMTP 
(1.37.109.16/15.5+ECS 3.3) id AAQ21345101; Wed, 20 Nov 1996 10:38:21 -0800 
Received: by polecat.sr.hp.com 
(1.37.109.16/15.5+ECS 3.3) id AAQ89115098; Wed, 20 Nov 1996 10:38:18 -0800 
From: Alan Bloom <alanb@polecat.sr.hp.com> 
Message-Id: <199611201838.AA089115098@polecat.sr.hp.com> 
Subject: S/H 
To: hfsig@tapr.org 
Date: Wed, 20 Nov 1996 10:38:17 -0800 (PST) 
X-Mailer: ELM [version 2.4 PL21] 
Mime-Version: 1.0 
Content-Type: text/plain; charset=US-ASCII 
Content-Transfer-Encoding: 7bit 


Phil Karn <karn@qualcomm.com> wrote: 


>>By the way, the sampling rate must be > 2x the bandwidth, not 2x the 
>>frequency. 

> 

>One comment here -- although the A/D converter can take its time when 
>the IF bandwidth is much less than the frequency, the sample-and-hold 
>used ahead of the A/D converter must still have a very short sample 
>time compared to the period of the RF waveform. As I understand it, 
>the sample-and-hold circuits are one of the limiting factors on the 
>performance of a digital radio that uses direct IF sampling. 


Good point. That's probably why a lot of radios with digital IF's 
go to the trouble of heterodyning down to a low IF frequency before 


digitizing. Designing a high-speed sample-and-hold is not trivial. 


But the S/H is the only part that has to run at 2x the IF frequency. 
The A/D and the DSP can run at the lower rate (2x bandwidth) . 


Al N1AL 


From rick@itron-ca.com Wed Nov 20 13:50:33 1996 


Received: from itron-ca.com (gate.itron-ca.com [204.30.20.2]) by tapr.org 

(8.7.5/8.7.3/1.9) with SMTP id NAAQ5887 for <hfsig@tapr.org>; Wed, 20 Nov 1996 

13:50:31 -0600 (CST) 

Received: (from audit@localhost) by itron-ca.com (8.6.9/8.6.9) id LAAQ1247 for 

<hfsig@tapr.org>; Wed, 20 Nov 1996 11:50:13 -0800 

Received: from unknown(204.30.20.214) by gate.itron-ca.com via smap (V1.3mjr) 
id sma001245; Wed Nov 20 11:49:39 1996 

Date: Wed, 20 Nov 96 11:48:14 

From: Rick Booth <rick@itron-ca.com> 

Subject: RE: [HFSIG:1729] S/H 

To: hfsig@tapr.org 

X-PRIORITY: 3 (Normal) 

X-Mailer: Chameleon 5.0, TCP/IP for Windows, NetManage Inc. 

Message-ID: <Chameleon.848519590.rick@rickb.itron-ca.com> 

MIME-Version: 1.0 

Content-Type: TEXT/PLAIN; charset=US-ASCII 


In spite of the fact the sampling process at the output of an IF 
can be performed at rates consistent with the BANDWIDTH there are 
certain s/h (and/or a/d) considerations that must account for the 
IF frequency being used, the most notable being the aperture 
jitter. Aperture jitter translates into phase noise and is worse 
as the IF frequency is increased. This is easily observed ina 
constellation plot at the output of a digital radio...good s/h's 
with low jitter look clean and lousy s/h's look noisy...no free 
lunch. 


Rick Booth 
'95 900SS SP 


E-mail: rick@itron-ca.com 


From k6sti@n2.net Wed Nov 20 17:32:28 1996 

Received: from ravel.n2.net (ravel.n2.net [204.250.22.20]) by tapr.org 
(8.7.5/8.7.3/1.9) with SMTP id RAA15291 for <hfsig@tapr.org>; Wed, 20 Nov 1996 
17:32:24 -0600 (CST) 

Received: from p154.n2.net (p154.n2.net [207.113.132.154]) by ravel.n2.net 
(8.6.12/8.6.12) with SMTP id PAA22647 for <hfsig@tapr.org>; Wed, 20 Nov 1996 
15:34:31 -0800 

Date: Wed, 20 Nov 1996 15:34:31 -0800 

Message-Id: <199611202334.PAA22647@ravel.n2.net> 

X-Sender: k6sti@mail.n2.net 

X-Mailer: Windows Eudora Version 1.4.4 
Mime-Version: 1.0 

Content-Type: text/plain; charset="us-ascii' 
To: hfsig@tapr.org 

From: k6ésti@n2.net (Brian Beezley) 

Subject: Re: [HFSIG:1730] RE: S/H 


>In spite of the fact the sampling process at the output of an IF 


>can be performed at rates consistent with the BANDWIDTH there are 
>certain s/h (and/or a/d) considerations that must account for the 
>IF frequency being used, the most notable being the aperture 
>jitter. Aperture jitter translates into phase noise and is worse 
>as the IF frequency is increased. This is easily observed ina 
>constellation plot at the output of a digital radio...good s/h's 
>with low jitter look clean and lousy s/h's look noisy...no free 
>lunch. 

>Rick 

>W6NZK 


>Rick Booth 
>'95 900SS SP 
>E-mail: rick@itron-ca.com 


I was wondering why the new radios with IF DSP use an 11-kHz or something 
last IF. Seemed crazy, but must be the S/H problem. 


Brian Beezley, K6STI 
k6sti@n2.net 


From k5cnf£1@juno.com Wed Nov 20 19:08:29 1996 
Received: from x9.boston.juno.com (x9.boston.juno.com [205.231.100.25]) by 
tapr.org (8.7.5/8.7.3/1.9) with ESMTP id TAA20049 for <hfsig@tapr.org>; Wed, 20 
Nov 1996 19:08:25 -0600 (CST) 
Received: (from k5cnf1@juno.com) by x9.boston.juno.com (queuemail) 
id UAA16795; Wed, 20 Nov 1996 20:02:22 EST 
To: hfsig@tapr.org 
Date: Wed, 20 Nov 1996 06:58:35 PST 
Subject: Re: TU-170 
Message-ID: <19961120.070032.8279.0.k5cnf£1@juno.com> 
References: <19961118.110303.7879.1.w5zit@juno.com> 
X-Mailer: Juno 1.00 
X-Juno-Line-Breaks: 0-6,9-16,19-26,35-36,38-39,44-64 
From: k5cnf1@juno.com (Richard B Morrow) 


>Take a look at the filtering after the mark/space detector and see if 
>the 

>output transitions are restricted to a slower rate. You may have to 
>decrease the value of one or more filter caps to get the higher data 
>rates. 

Can you explain what I am going to look for? I got to thinking about it 
and realized that I just might not have a clue... which is not unusual 
at times. 


>There are several packages that run RTTY from a PC that would require 


>no mod to the TU-170 at all - except for perhaps an adapter to get the 
>RS-232 levels conditions for your PC. I don't recall if the I/0 of 
>the TU-170 is RS-232 compatable or just TTL - but you probably have all 
>the specs there in your docs. 


this ne does not have the RS-232 output but I think that there were some mods to 
add that in the documentation I have.. Just have to look for it I 
guess 


>I have used an Amtor freebie program on HF with some success, and the 
>TU-170 should work well on Amtor with the Baud filter modified to pass 
>the 100 Baud data. On the other hand - if the Flesher specs say it was 
>designed to pass 100 Baud RTTY signals - then no modification would be 
>required for Amtor. 


That would be a real deal if I could find it. My Rig is a TS-430 and I 

can whip up just about anything to interface it. I am busy with repairs 

on my motorcycle and car, Plus I am doing voulinteer work at the local 
museum. Don't know if you have been seeing anything in your local paper 

about the shipwreck in Matagorda Bay, The La Belle, which was one of the 

La Salle expedition ships that went aground in 1686 or so. The cannon 

that came up from that wreck was a real beauty. BUT I digress. I am doing the 
electronics for the reverse electrolysis that gets the salt out of 

the metal out of whatever they pull out out of the slat water. 


I figure that the TU 170 could be used for just about anything with the 
right program was to be had. 


I do appreciate your input to the smoke testing that will be conducted 

later when I get all of the stuff hooked up.. By the way what bands are you on any 
way I can be found on 7.213 at times, but right now I am sort of off the air while 
I move furnature in the shack so I can have anothe 

desk to pile more stuff on and cover everything up even better.. 


73, Richard, K5CNF 


>There is a program that can be purchased to run Pactor to an external 
>modem also - which would require modifying the TU-170 Baud fliter to 
>pass 

>the 200 Baud Pactor signals. I do not recall the name of the program 
>- 

>but I have worked several hams using it. 

> 

>Look on the QRZ CD Rom for programs that run on the PC to run various 
>modes. You may have some ham buddies who have that CD who can help. 
> 

>If you have trouble locating any of the specific programs - let me 
>know 

>and I will see what I can dig up. 

> 

>73 - Jim - w5zit@juno.com 

> 

> 


From lylej@azstarnet.com Wed Nov 20 22:59:15 1996 

Received: from mailhost.azstarnet.com (mailhost.azstarnet.com [169.197.1.8]) by 
tapr.org (8.7.5/8.7.3/1.9) with ESMTP id WAAQ4032 for <hfsig@tapr.org>; Wed, 20 
Nov 1996 22:59:10 -0600 (CST) 

Received: from tomswift2 (usr5ip57.azstarnet.com [169.197.6.57]) by 
mailhost.azstarnet.com (8.8.2-pb2/8.8.2) with SMTP id VAA12822 for 
<hfsig@tapr.org>; Wed, 20 Nov 1996 21:56:24 -0700 (MST) 

Date: Wed, 20 Nov 1996 21:56:24 -0700 (MST) 

Message-Id: <1.5.4.32.19961120215749 .00371cb8@pop.azstarnet.com> 

X-Sender: lylej@pop.azstarnet.com 

X-Mailer: Windows Eudora Light Version 1.5.4 (32) 

Mime-Version: 1.0 

Content-Type: text/plain; charset="us-ascii" 

To: hfsig@tapr.org 

From: Lyle Johnson <lylej@azstarnet.com> 

Subject: Re: [HFSIG:1732] Re: TU-170 


Richard, 


>That would be a real deal if I could find it. My Rig is a TS-430 and I 
>can whip up just about anything to interface it. 


N7CL wrote up some mods that you'll want to do to your TS430S if you plan on 
using it for AMTOR or any other fast switching mode between receive and 
transmit. It was in PSR several years ago. I did it to my '430 back when I 
owned one and it made the difference between being a useful rig for AMTOR 
and a not very useful rig. 


Cheers, 
Lyle 


From wd5ivd@tapr.org Thu Nov 21 01:50:33 1996 

Received: from [128.83.113.72] (slip-a-8.ots.utexas.edu [128.83.113.72]) by 
tapr.org (8.7.5/8.7.3/1.9) with ESMTP id BAA18796 for <hfsig@tapr.org>; Thu, 21 
Nov 1996 01:50:30 -0600 (CST) 

Message-Id: <v03007806aeb99cbd4ec7@[128.83.176.153]> 

In-Reply-To: <1.5.4.32.19961120215749 .00371cb8@pop.azstarnet.com> 
Mime-Version: 1.0 

Content-Type: text/plain; charset="us-ascii" 

Date: Wed, 20 Nov 1996 23:45:36 -0600 

To: hfsig@tapr.org 

From: "Greg Jones, WD5IVD" <wd5ivd@tapr.org> 

Subject: Re: [HFSIG:1733] Re: TU-170 


The index of articles is on the web page under PSR link on the top page 
http://www.tapr.org It is in XLS, CSV, and TXT formats. Should be easy 


enough to search and locate. 


Cheers - Greg, WD5IVD 


>Richard, 

> 

>>That would be a real deal if I could find it. My Rig is a TS-430 and I 
>>can whip up just about anything to interface it. 

> 

>N7CL wrote up some mods that you'll want to do to your TS430S if you plan on 
>using it for AMTOR or any other fast switching mode between receive and 
>transmit. It was in PSR several years ago. I did it to my ‘430 back when I 
>owned one and it made the difference between being a useful rig for AMTOR 
>and a not very useful rig. 

> 

>Cheers, 

> 

>Lyle 


Greg Jones, WD5IVD 

Austin, Texas 
wd5ivd@tapr.org 

http: //www.tapr.org/~wd5ivd 


From lylej@azstarnet.com Thu Nov 21 09:03:05 1996 

Received: from mailhost.azstarnet.com (mailhost.azstarnet.com [169.197.1.8]) by 
tapr.org (8.7.5/8.7.3/1.9) with ESMTP id JAAQ2449 for <hfsig@tapr.org>; Thu, 21 
Nov 1996 09:03:02 -Q600 (CST) 

Received: from tomswift2 (usr6ip26.azstarnet.com [169.197.7.26]) by 
mailhost.azstarnet.com (8.8.3-p/8.8.2) with SMTP id IAA09167 for <hfsig@tapr.org>; 
Thu, 21 Nov 1996 08:00:17 -0700 (MST) 

Date: Thu, 21 Nov 1996 08:00:17 -0700 (MST) 

Message-Id: <1.5.4.32.19961121080143 .0030bb7c@pop.azstarnet.com> 

X-Sender: lylej@pop.azstarnet.com 

X-Mailer: Windows Eudora Light Version 1.5.4 (32) 

Mime-Version: 1.0 

Content-Type: text/plain; charset="us-ascii" 

To: hfsig@tapr.org 

From: Lyle Johnson <lylej@azstarnet.com> 

Subject: Re: [HFSIG:1734] Re: TU-170 


At 01:56 AM 11/21/96 -0600, you wrote: 

>The index of articles is on the web page under PSR link on the top page 
>http://www.tapr.org It is in XLS, CSV, and TXT formats. Should be easy 
>enough to search and locate. 


Yep! Jan '86, Issue 18, page 11. 


From jtpjatae@bicc00.bi.ehu.es Thu Nov 21 12:42:51 1996 

Received: from biccO0O.bi.ehu.es (biccO0O.bi.ehu.es [158.227.65.40]) by tapr.org 
(8.7.5/8.7.3/1.9) with SMTP id MAA14478 for <hfsig@tapr.org>; Thu, 21 Nov 1996 
12:42:02 -Q600 (CST) 

Received: from bipt71.bi.ehu.es by bicc00.bi.ehu.es (AIX 3.2/UCB 5.64/4.03) 


id AA38665; Thu, 21 Nov 1996 19:44:56 GMT 
Message-Id: <9611211944.AA38665@bicc00.bi.ehu.es> 
Comments: Authenticated sender is <jtpjatae@bicc00.bi.ehu.es> 
From: "Eduardo Jacob" <jtpjatae@bicc00.bi.ehu.es> 
Organization: ETSII y de IT, Bilbao, UPV/EHU 
To: hfsig@tapr.org 
Date: Thu, 21 Nov 1996 19:41:36 +0000 
Subject: Spanish Article about EVM56002 
Reply-To: jtpjatae@bicc00.bi.ehu.es 
Priority: normal 
X-Mailer: Pegasus Mail for Win32 (v2.42a) 


I have just setup a page with an article written by Jabi EA2ARU 

and me. It is inspired in Johan's one and is going to be published 
in a Spanish Amateur Magazine (I think) in December. It mentions 

the work of several people and it is meant to be a contribution 

to the spanish speaking ham comunity in order to help them beginning 
to play with the EVM. I think there will be another soon. 


The article is meant to be a living article so I welcome any 
comments about it. It is located at 


http://bipt.bi.ehu.es/~jtpjatae/articulo.html 


These pages are my first ones, so contributions and comments are 
welcome. 


Eduardo EA2BAJ 


Eduardo Jacob - Area de Ingenieria Telematica 
Departamento de Electronica y Telecomunicaciones 


ETSII y de IT Tel: +34-(9)4-427 8055 

UPV / EHU Fax: +34-(9)4-441 4041 

Alda Urquijo s/n E-mail: jtpjatae@bi.ehu.es 
E-48013 - Bilbao (Spain) : 100021,2212 Compuserve 
Ham: EA2BAJ VHF PACKET: EA2BAJ @ EA2URV 


From rwmcgwier@worldnet.att.net Thu Nov 21 20:30:39 1996 
Received: from mtigwc02.worldnet.att.net (mailhost.worldnet.att.net 
[204.127.129.4]) by tapr.org (8.7.5/8.7.3/1.9) with ESMTP id UAAQ5921 for 
<hfsig@tapr.org>; Thu, 21 Nov 1996 20:30:35 -0600 (CST) 
Received: from dad.ccr-p.ida.org ([207.116.39.164]) 
by mtigwc02.worldnet.att.net (post.office MTA v2.0 0613 ) 
with SMTP id AAA24037 for <hfsig@tapr.org>; 
Fri, 22 Nov 1996 02:30:19 +0000 
Message-ID: <32950F6C.19D4@worldnet.att.net> 
Date: Thu, 21 Nov 1996 21:26:52 -0500 
From: Robert McGwier <rwmcgwier@worldnet.att.net> 
Reply-To: rwmcgwier@worldnet.att.net 
Organization: N4HY Software 
X-Mailer: Mozilla 3.0Gold (Win95; I) 
MIME-Version: 1.0 


To: hfsig@tapr.org 

Subject: Re: [HFSIG:1720] Sigma Delta 

References: <199611182256.AA067387805@polecat.sr.hp.com> 
Content-Type: text/plain; charset=us-ascii 
Content-Transfer-Encoding: 7bit 


Alan Bloom wrote: 

I promised to try to find a reference explaining Sigma-Delta A/D converters. 
None of my DSP textbooks seem to cover the topic. I did find an app note 
from Harris Semiconductor (AN9504, May 1995) that does a pretty good job. 


I can copy it if anyone is interested. 


Basically a sigma-delta converter is formed thus: 


VVVVV VV WV 


What follows had all the elements, but hooked up incorrectly. 
The one bit DAC output is integrated for a very short period of 
time. The output of the integrator is fed into the summer 

where it is subtracted from the Analog Input. This goes into 
the comparator where the Digital output comes and the error 
Signal tells the DAC whether over the next period of integration 
it should output plus or minus voltage. Now it should make more 
logical sense to you as it is doing proportional guidance with 
bang bang control if you want to go look at an old control 
theory book. This is the simplest sigma-delta ADC. They get 
much fancier. 


Bob 


KKKKAIKKKKIKK KKK KKK KAKA KKK AKA AK AKAIKE K AKAIKE KAKA KAKA KA KAEKAKAEKAKAEKAKEREKRERE 
* Robert W. McGwier, Ph.D. * Mathematician. Hobbies: Computers, 


Astronomyx 

x 64 Brooktree Rd. x Amateur Radio. Scouts: Council Commissioner 
: East Windsor, NJ 08520 x Post 995 Advisor, Troop 5700 Advancement, 

: (H) 609-443-8963 * Sanhican #2 (Brotherhood), Used to be a 

* 

* (F) 609-924-3061 * Buffalo (NE-III-120). George Washington 

: (W) 609-279-6240 * Council. Brownie Troop 193 

* 


KKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKEKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKAKK 


From alanb@polecat.sr.hp.com Fri Nov 22 14:30:09 1996 

Received: from palrel1.hp.com (palrel1.hp.com [15.253.72.10]) by tapr.org 
(8.7.5/8.7.3/1.9) with ESMTP id 0AA26164 for <hfsig@tapr.org>; Fri, 22 Nov 1996 
14:30:07 -0600 (CST) 

Received: from srmail.sr.hp.com (srmail.sr.hp.com [15.4.45.14]) by palrel1.hp.com 
with ESMTP (8.7.5/8.7.3) id MAAQ1061 for <hfsig@tapr.org>; Fri, 22 Nov 1996 
12:30:05 -0800 (PST) 

Received: from polecat.sr.hp.com (algae.sr.hp.com) by srmail.sr.hp.com with ESMTP 


(1.37.109.16/15.5+ECS 3.3) id AA211294605; Fri, 22 Nov 1996 12:30:05 -0800 
Received: by polecat.sr.hp.com 
(1.37.109.16/15.5+ECS 3.3) id AAQ82054604; Fri, 22 Nov 1996 12:30:04 -0800 
From: Alan Bloom <alanb@polecat.sr.hp.com> 
Message-Id: <199611222030.AA082054604@polecat.sr.hp.com> 
Subject: Re: Sigma Delta 
To: hfsig@tapr.org 
Date: Fri, 22 Nov 1996 12:30:04 -0800 (PST) 
X-Mailer: ELM [version 2.4 PL21] 
Mime-Version: 1.0 
Content-Type: text/plain; charset=US-ASCII 
Content-Transfer-Encoding: 7bit 


Robert McGwier <rwmcgwier@worldnet.att.net> wrote: 


>Alan Bloom wrote: 

>> 

>> I promised to try to find a reference explaining Sigma-Delta A/D converters. 
>> None of my DSP textbooks seem to cover the topic. I did find an app note 
>> from Harris Semiconductor (AN9504, May 1995) that does a pretty good job. 

>> I can copy it if anyone is interested. 


>> Basically a sigma-delta converter is formed thus: 


>What follows had all the elements, but hooked up incorrectly. 
>The one bit DAC output is integrated for a very short period of 
>time. The output of the integrator is fed into the summer 
>where it is subtracted from the Analog Input. This goes into 
>the comparator where the Digital output comes and the error 
>signal tells the DAC whether over the next period of integration 
>it should output plus or minus voltage. Now it should make more 
>logical sense to you as it is doing proportional guidance with 
>bang bang control if you want to go look at an old control 
>theory book. This is the simplest sigma-delta ADC. They get 
>much fancier. 


I think what you're describing is this: 


AMALOS. ) owe te ce ee 
Input ---->|+ | | Comparator | 
| Summer |--->| (12-bit A/D) |----*----> digital output 
art Se ok | [ee a as ee | | 
| | 
lp iste de es Beare | 
| | | | | | 
+---| Integrator |<---| 1-bit D/A |<---+ 


That is actually a "Delta" converter. Compared to a Sigma-Delta 
converter it has the disadvantage that there is a slew rate limit 
on the input signal. A high-amplitude, high-frequency analog input 
will exceed the slew rate capability of the integrator, causing 


severe distortion. That's not too serious a constraint for codec 
applications, because most of the energy in the human voice is at 
low frequencies. The high-frequency energy is low enough not to 
exceed the maximum slew rate. 


It's called a "Delta" converter because the digital output represents 
the rate of change (delta) at the input. A continuous DC input voltage 
causes the digital output to represent zero volts (+1 half the time, 

-1 half the time). To recover the audio, you have to integrate the 
output (run it through a -6 dB per octave filter). 


Another way to view the slew-rate problem is to note that the digital 
output represents the slope (time rate of change) of the input signal. 
The slew rate limit is the point where the output is all +1's or -1's. 


In a Sigma-Delta converter, the integrator is moved from the input 
to the output of the summer. That solves the slew rate problem and 
gives a flat output frequency response. 


Alan Bloom N1AL 


From rwhiting@winternet.com Fri Nov 22 18:12:37 1996 
Received: from icicle.winternet.com (adm@icicle.winternet.com [198.174.169.5]) by 
tapr.org (8.7.5/8.7.3/1.9) with ESMTP id SAAQ5891 for <hfsig@tapr.org>; Fri, 22 
Nov 1996 18:12:34 -0Q600 (CST) 
Received: (from adm@localhost) by icicle.winternet.com (8.7.5/8.7.5) id SAA09966 
for <hfsig@tapr.org>; Fri, 22 Nov 1996 18:12:32 -0600 (CST) 
Date: Fri, 22 Nov 1996 18:12:32 -0600 (CST) 
Posted-Date: Fri, 22 Nov 1996 18:12:32 -0600 (CST) 
Message-Id: <199611230012.SAA09966@icicle.winternet.com> 
Received: from ppp-67-24.dialup.winternet.com(204.246.67.24) by 
icicle.winternet.com via smap (V2.Qbeta) 
id xmab09788; Fri, 22 Nov 96 18:12:08 -0600 
X-Sender: rwhiting@mail.winternet.com 
X-Mailer: Windows Eudora Light Version 1.5.2 
Mime-Version: 1.0 
Content-Type: text/plain; charset="us-ascii" 
To: hfsig@tapr.org 
From: Rick Whiting <rwhiting@winternet.com> 
Subject: Re: Sigma Delta 


There is a discussion of sigma-delta converters in: 
Pohlmann, K.C. (1991). "Advanced Digital Audio." Carmel, IN: SAMS 


e.g., p. 407-408, 413-414. For example, there is an internal block diagram 
of a DSP56ADC16 sigma-delta A/D converter on p. 413. 


Regards/ Rick WOTN 


Richard A. (Rick) Whiting Home Phone: + 1 612 550 1213 
RF Engineer, AirTouch Cellular Work Phone: + 1 612 595 5065 


5780 Rosewood Ln. N. E-mail: rwhiting@winternet.com 
Plymouth, MN 55442-1411 Packet: WOTN @ WBOGDB.MN.USA.NOAM 


From karn@qualcomm.com Mon Nov 25 23:42:37 1996 

Received: from servo.qualcomm.com (servo.qualcomm.com [129.46.101.170]) by 
tapr.org (8.7.5/8.7.3/1.9) with ESMTP id XAA20183 for <hfsig@tapr.org>; Mon, 25 
Nov 1996 23:42:34 -0600 (CST) 

Received: (from karn@localhost) by servo.qualcomm.com (8.8.3/1.4/8.7.2/1.9) id 
VAA27906; Mon, 25 Nov 1996 21:42:02 -0800 (PST) 

Date: Mon, 25 Nov 1996 21:42:02 -@800 (PST) 

From: Phil Karn <karn@qualcomm. com> 

Message-Id: <199611260542.VAA27906@servo.qualcomm. com> 

To: hfsig@tapr.org 

In-reply-to: <199611192141.AA095919670@polecat.sr.hp.com> (message from Alan Bloom 
on Tue, 19 Nov 1996 15:45:48 -0600 (CST)) 

Subject: Re: [HFSIG:1726] RTTY 


>In designing the receiver, you wouldn't go far wrong to assume that 
>there is no transmit filter and that each mark or space tone is held 
>for the entire duration of the symbol as Phil illustrated above. The 


If this is true, then the transmitted spectrum would have a "comb" 
(sin(x)/x) shape and the simplest matched filter would be an 
integrate-and-dump. 


That is, if you can form a local estimate of the mark and space tones, 
simply multiply the incoming signal separately by the local mark & 
Space estimates, square each to compute power, subtract one from the 
other and integrate the result over the bit interval. Sample at the 
end of the bit interval and you have your decision variable. 


In other words, integrate 
cos(2xpixfmarkxt)«s(t))**2 - cos(2xpixfspacext)x«s(t))**2 


over the bit interval. If the result is positive, you have a mark. If 
negative, you have a space. Or you can use the numerical result as a 
soft decision sample for a Viterbi decoder. Dump the accumulated value 
and start again at 0 for the next bit. 


This is a classic optimum noncoherent demodulator, with the signal 
pulse shaping omitted because it's square to begin with. Note that 
you don't need knowledge of mark & space phase, only their frequencies, 
and then only accurately enough so that the phase "drift" over a bit 
interval is acceptably small. The faster the data rate, the sloppier 
your frequency estimate can be. 


Phil 
From karn@unix.ka9q.ampr.org Tue Nov 26 05:39:51 1996 


Received: from unix.ka9q.ampr.org (karn@unix.ka9q.ampr.org [129.46.90.35]) by 
tapr.org (8.7.5/8.7.3/1.9) with ESMTP id FAAQ6984 for <hfsig@tapr.org>; Tue, 26 


Nov 1996 05:39:49 -Q600 (CST) 

Received: (from karn@localhost) by unix.ka9q.ampr.org (8.7.4/8.7.3) id DAA02000; 
Tue, 26 Nov 1996 03:39:39 -0800 (PST) 

Date: Tue, 26 Nov 1996 03:39:39 -0800 (PST) 

Message-Id: <199611261139 .DAAQ2000@unix.ka9q.ampr.org> 

From: Phil Karn <karn@unix.ka9q.ampr.org> 

To: hfsig@tapr.org 

In-reply-to: <199611260542.VAA27906@servo.qualcomm.com> (karn) 

Subject: Re: [HFSIG:1740] Re: RTTY 


A correction. The optimum noncoherent demodulator should integrate 
the following over the bit interval: 


cos(2*pixfmarkxt)*s(t))**2 + sin(2*pixfmarkxt)x*s(t))**2 
- [cos(2xpixfspacext)*s(t))**2 + sin(2xpixfspacext)«s(t))**2 ] 


That is, the mark detector should produce the sum of the energies 
received in both the in-phase and quadrature channels with respect 
to the mark carrier reference, and similarly with the space detector. 


The decision variable is, as before, the difference between the total 
energies seen in these two channels over the bit interval. 


By the way, the matched filter detector can be implemented in one 
of two ways. 


The first way is to sample the output of a bandpass filter whose 
response is the complex conjugate of the signal spectrum. "Complex 
conjugate" simply means that the amplitude response is the same, and 
the phase response is adjusted to correct for any frequency dispersion 
in the signal. 


The second way is to multiply the incoming signal by a local 
time-reversed replica of the signal's nominal pulse shape, integrate 
over a bit interval, then sample. (If the nominal pulse shape is 
symmetrical, then the time-reversal isn't noticeable). 


These two ways are in fact exactly equivalent. This is most easily 
seen when you use a FIR (finite impulse response) filter to implement 
method #1, as it does exactly the same thing as method #2 -- 
multiplying the incoming signal by the time-reversed replica of the 
nominal pulse shape and summing (integrating) the results. 


Phil 


From Robert.Glassey@nmp.nokia.com Tue Nov 26 23:47:05 1996 

Received: from noknic.nokia.com (noknic.nokia.com [131.228.6.10]) by tapr.org 
(8.7.5/8.7.3/1.9) with SMTP id XAA22144 for <hfsig@tapr.org>; Tue, 26 Nov 1996 
23:47:03 -0600 (CST) 

From: Robert.Glassey@nmp.nokia.com 

Received: from samail01.nmp.nokia.com (samail01.nmp.nokia.com [131.228.240.6]) by 
noknic.nokia.com (8.6.9/8.6.9) with ESMTP id HAA29466 for <hfsig@tapr.org>; Wed, 


27 Nov 1996 07:25:20 +0200 

Received: from by samail01.nmp.nokia.com with SMTP 
(1.37.109.20/16.2) id AA143582238; Wed, 27 Nov 1996 07:23:58 +0200 

X-Openmail-Hops: 2 

Date: Tue, 26 Nov 96 13:37:55 +0000 

Message-Id: <H0Q00029202dadbaf@MHS> 

In-Reply-To: <199611261139 .DAAQO2000@unix.ka9q.ampr.org> 

Subject: [HFSIG:1741] Re: RTTY 

Mime-Version: 1.0 

Sender: Robert.Glassey@nmp.nokia.com 

To: hfsig@tapr.org 

Content-Type: text/plain; charset=US-ASCII; name="[HFSIG:1741]" 

Content-Transfer-Encoding: 7bit 


A correction. The optimum noncoherent demodulator should integrate 
the following over the bit interval: 


cos(2*pixfmarkxt)*s(t))**2 + sin(2*pixfmarkxt) xs (t))**2 
- [cos(2*pixfspacext)*s(t))**2 + sin(2*xpixfspacext)x*s(t))«**2 ] 


That is, the mark detector should produce the sum of the energies 
received in both the in-phase and quadrature channels with respect 
to the mark carrier reference, and similarly with the space detector. 


VV VVV VV VV 


This sounds better, I was a bit confused by your pervious post. I have 
implimented something similar in BTL for the ‘Narrow’ mode. But instead 
of summing the squares of I and Q, I simple take the magnitude of I+jQ, 
and compare the magnitudes. This would not be as good for a soft 
decision variable, but it has no effect on the result of a hard decision 
comparison between mark and space, ie is |A|>|B| then AxA > BxB. Since 
RTTY has no way of detecting errors, this seems optimal to me. 


However in actual practice, I find this method is rarely any better than 
my non-optimnal detection, which simply uses +/- 100Hz filters (+/-170Hz 
nulls) and takes the amplitude, then does the bit period intergration. 
My overall receiver filter impulse is fairly rounded, complete with ISI, 
and suffers from amplitude detection between the filter and the bit 
period integrator, but still, it actually appears to work just as well 
as the optimum solution, better if practicalities of tuning, listening 
to several stations with slightly different frequencies, and the 
170/200Hz shift uncertianty, are considered. 


I suspect the lower tollerance to tuning of the optimal detection method 
means that if the optimal method is slightly off tune, by say 20Hz, then 
you have lost the few dB you might have gained, where the non-optimal 
solution can work OK +/-75Hz off, looseing a few more dB of course, but 
less than you would have lost with narrower filters. 


If the optimal solution is more sensitive, in practice it makes little 
difference given the fading nature of the channel, and the tuning 
uncertainties. I have only ever got a significant improvement in 
performance using the optimal filters when there as another RTTY signal 
on the same frequency (shifted by maybe 50Hz) where I was able to filter 


it out. Of course its very rear that this can be done. 
Cheers, 
Rob 


From karn@qualcomm.com Wed Nov 27 01:42:27 1996 

Received: from servo.qualcomm.com (servo.qualcomm.com [129.46.101.170]) by 
tapr.org (8.7.5/8.7.3/1.9) with ESMTP id BAAQ3860 for <hfsig@tapr.org>; Wed, 27 
Nov 1996 01:42:25 -0600 (CST) 

Received: (from karn@localhost) by servo.qualcomm.com (8.8.3/1.4/8.7.2/1.9) id 
XAA01372; Tue, 26 Nov 1996 23:41:54 -0800 (PST) 

Date: Tue, 26 Nov 1996 23:41:54 -@800 (PST) 

From: Phil Karn <karn@qualcomm. com> 

Message-Id: <199611270741.XAA0Q1372@servo.qualcomm. com> 

To: hfsig@tapr.org 

In-reply-to: <H000029202dadbaf@MHS> (Robert.Glassey@nmp.nokia.com) 

Subject: Re: [HFSIG:1742] Re: RTTY 


>This sounds better, I was a bit confused by your pervious post. I have 
>implimented something similar in BTL for the 'Narrow' mode. But instead 
>of summing the squares of I and Q, I simple take the magnitude of I+jQ, 
>and compare the magnitudes. This would not be as good for a soft 


"Taking the magnitude of I+jQ" normally implies taking the sum of the 
squares of the real and imaginary components, but from the later 
context I assume you mean simply summing the amplitudes of the real 
and imaginary components without any squaring operation? 


If so, this is suboptimal even in an uncoded hard-decision 
situation. Consider the following example in which your demodulator 
algorithm makes an error while the optimal one does not: 


Assume the mark channel integrator gives the complex result .707 + 
.707} while the space channel integrator gives the result 1.3 + 

Q.0j. The space channel clearly has the stronger signal with magnitude 
sqrt(1.3**2 + Q**2) = 1.3 as compared to the mark channel's 
sqrt(.707**2 + .707**2) = 1.0. Yet your algorithm would give a 
magnitude of 1.414 for the mark channel, causing it to be chosen in 
error over the space channel. 


Phil 


From Robert.Glassey@nmp.nokia.com Thu Nov 28 04:04:14 1996 
Received: from noknic.nokia.com (noknic.nokia.com [131.228.6.10]) by tapr.org 
(8.7.5/8.7.3/1.9) with SMTP id EAA11050 for <hfsig@tapr.org>; Thu, 28 Nov 1996 
04:04:12 -Q600 (CST) 
From: Robert.Glassey@nmp.nokia.com 
Received: from samail01.nmp.nokia.com (samail01.nmp.nokia.com [131.228.240.6]) by 
noknic.nokia.com (8.6.9/8.6.9) with ESMTP id MAAQ4707 for <hfsig@tapr.org>; Thu, 
28 Nov 1996 12:03:35 +0200 
Received: from by samail01.nmp.nokia.com with SMTP 

(1.37.109.20/16.2) id AA176045329; Thu, 28 Nov 1996 12:02:09 +0200 


X-Openmail-Hops: 2 

Date: Thu, 28 Nov 96 10:00:04 +0000 

Message-Id: <H000029202df£f828@MHS> 

Subject: Re: RTTY 

Mime-Version: 1.0 

Sender: Robert.Glassey@nmp.nokia.com 

To: hfsig@tapr.org 

Content-Type: text/plain; charset=US-ASCII; name="Re:" 
Content-Transfer-Encoding: 7bit 


Assume the mark channel integrator gives the complex result .707 + 
.707} while the space channel integrator gives the result 1.3 + 

@.0j. The space channel clearly has the stronger signal with magnitude 
sqrt(1.3**2 + Q**2) = 1.3 as compared to the mark channel's 
sqrt(.707**2 + .707**2) = 1.0. Yet your algorithm would give a 
magnitude of 1.414 for the mark channel, causing it to be chosen in 
error over the space channel. 


VV VV VV MV 


Sorry, yes, I agree. Perhaps I didn't explain clearly enough. The 
amplitude I use is the magnitude of the complex vector ie sqrt(I«*I + 
QxQ), although in actual practice I use a much faster approximation 
which is accurate to about 1%. If I were to use squares I would need to 
use 32 bit words or floating point, and there is no advantage for hard 
decisions. I can always square the magnitude later if needed, and ovoid 
carrying around 32 bit or floating point variables. 


Cheers, 
Rob 


From s56éa@s55tcp.ampr.org Thu Nov 28 06:12:41 1996 

Received: from s55tcp.ampr.org (ljutcp.hamradio.si [193.2.132.80]) by tapr.org 
(8.7.5/8.7.3/1.9) with SMTP id GAA14403 for <hfsig@tapr.org>; Thu, 28 Nov 1996 
06:12:39 -Q600 (CST) 

Date: Thu, 28 Nov 96 12:05:27 EST 

Message-Id: <20383@s55tcp.ampr.org> 

From: Marijan Miletic <s56a@s55tcp.ampr.org> 

Reply-To: S56A@s55tcp.ampr.org 

To: hfsig@tapr.org 

Subject: Re: RTTY 


Following my previous KISS postings, it is well known that IQ power can be also 
calculated as sum of larger signal with 0.4 of smaller. I use right shift for 
1/2 of smaller signal... 
73 de Mario, S56A, N1YU. 


From Robert.Glassey@nmp.nokia.com Thu Nov 28 12:24:12 1996 

Received: from noknic.nokia.com (noknic.nokia.com [131.228.6.10]) by tapr.org 
(8.7.5/8.7.3/1.9) with SMTP id MAA27465 for <hfsig@tapr.org>; Thu, 28 Nov 1996 
12:24:10 -0600 (CST) 

From: Robert.Glassey@nmp.nokia.com 

Received: from samail01.nmp.nokia.com (samail01.nmp.nokia.com [131.228.240.6]) by 
noknic.nokia.com (8.6.9/8.6.9) with ESMTP id UAA19560 for <hfsig@tapr.org>; Thu, 
28 Nov 1996 20:23:34 +0200 


Received: from by samail01.nmp.nokia.com with SMTP 
(1.37.109.20/16.2) id AA214725328; Thu, 28 Nov 1996 20:22:08 +0200 

X-Openmail-Hops: 2 

Date: Thu, 28 Nov 96 18:20:23 +0000 

Message-Id: <H0Q00029202dff83a@MHS> 

In-Reply-To: <20383@s55tcp.ampr.org> 

Subject: [HFSIG:1745] Re: RTTY 

Mime-Version: 1.0 

Sender: Robert.Glassey@nmp.nokia.com 

To: hfsig@tapr.org 

Content-Type: text/plain; charset=US-ASCII; name="[HFSIG:1745]" 

Content-Transfer-Encoding: 7bit 


> Following my previous KISS postings, it is well known that IQ power 

> can be also calculated as sum of larger signal with 0.4 of smaller. I 
> use right shift for 1/2 of smaller signal... 

Sounds nice an simple! 

Here's my one 

T=abs(T) 

Q=abs (Q) 

if (Q>1I) swap I and Q 


If (Q>I1/2) M = I*7/8 + Qx9/16 
else M= I + Q/4 


Shift and adds are used for the fractions. 


My ASM code for this takes 0.9uS on my 486DX-2 / 80MHz 


For phase: 

phase = table[Q/(1I+Q], for 0-45 degrees. 

256 entries in table for 45 degrees 

The Q/(I+Q) is an approximate phase to get reasonable linearity for the 
table index, and the table values are 16 bits, used as a correction 
table. Thus there are 256*8=2048 discernible phases. 

I haven't done timing for this, but I expect it is faster than the ABS 
function, since there are no shift and adds, but one multiply. 


Cheers, 


Rob 


